I think your harness and system prompt matter much more than whatever workflow or skills you are using.
I have seen a lot of new developers, and just people trying to get into AI, immediately launch into plugins like OyePi or Superpowers or whatever the most feature-filled harness is that week.
And I think that makes sense for a lot of beginners.
Probably for the first month or so, as you learn, that kind of setup can be useful. It gives you a bunch of buttons to press. It gives you a feeling for what these agents can do.
But there are a few things you should know about how much weight those tools take up, and how much they steer your agent before you even start doing the work.
Because there is not really one single harness, I am going to keep this a little more general and talk about some of the standards that have come out and how to set them. I am going to use Pi as the example, because that is what I use most. I may talk a little bit about Claude Code too, because it is a good contrast.
Minimal harnesses are stronger than they look
The Pi harness is a very minimal agent harness.
It does not have subagents built into the core. It does not try to make MCP the whole personality of the tool. It does not ship as this giant agent operating system where every feature is already loaded into the model’s face.
What it has is the boring stuff:
- bash
- read
- write
- edit
- tool calls
- batched tool calls
Turns out those things are insanely powerful.
If you look at the Pi harness and its system prompt versus something like the Claude Code system prompt, and people in the community usually extract these whenever a new harness comes out, you see a huge difference immediately.
Pi is tiny.
Claude Code is much heavier. It has a lot more instruction around how to approach work, how to use tools, how to plan, how to run tasks, how to manage its own process, and so on.
That is not automatically bad. But it is not free.
Context size is not just a cost problem
Before we get too deep into the weeds, just focus on context size.
On the Pi side, the harness instructions take a very small amount of context.
On the Claude Code side, the harness itself can take a meaningful chunk of the context window before you have even started guiding the agent.
I am not making a cost argument here.
Anthropic likely caches a lot of this. Providers have their own tricks to make sure you are not literally paying the full sticker price every single time those shared tokens are used.
That is not the point.
The point is that your model has a finite amount of space.
That space is the context window.
Within that finite amount of space, you can only allocate so much attention to the task, the codebase, the project rules, the tools, the user’s instruction, and whatever the harness decided to preload.
It is like buying a phone advertised with a certain amount of storage, then finding out a huge chunk of it is already occupied by the operating system, vendor apps, carrier apps, and whatever else got bundled in before you touched it.
Sure, technically the phone has that much storage.
But you do not actually have all of that space available for your work.
Whether that is a perfect analogy or not, I do not care. It illustrates the point.
A heavier harness spends more of the model’s working space before your project even enters the conversation.
Skills add up faster than people think
Now add skills.
Say you are brand new and you install a bunch of skills because they all sound useful.
Even if the average skill only adds a title and a description, and even if the description is only four lines, ten skills is already forty lines of context telling the agent about ten different things it might need to do.
That is before the skill body loads.
And if those skills conflict, it gets worse.
Maybe you have a copywriting skill. Then you install a second copywriting skill to play around with and forget to remove the first one.
Now the agent has to decide which one matters. It has to spend some amount of attention figuring out what to pick. It may blend them. It may choose the wrong one. It may follow the one that is less relevant to your project.
That does not mean skills are bad.
It means skills are instructions.
And instructions are not weightless.
The heavier harness also brings its own workflow opinions
On the Claude Code side, it also loads your skills. It also knows how to run tasks, how to use planning tools, how to use the task tool, and how to use the rest of the harness-specific workflow surface.
Pi does not start there.
So if you compare the two setups before any real project work begins, the Pi side has taken up much less space than the heavier harness side.
And this is before MCP servers.
MCP servers also have descriptions. They also introduce tools. They also put names, capabilities, schemas, and behavioral possibilities into the model’s context.
Again, useful.
Again, not free.
Then you get to the project rules.
This is where AGENTS.md or CLAUDE.md becomes important.
Your project rules may already be too late
If you spend any time in vibe-coding spaces online, you see people constantly complain that the model does not follow their CLAUDE.md.
That file is supposed to be an additional way to communicate with the agent.
It is where you set project rules, document structure, explain workflow, define coding standards, and treat the repo like it has a map.
There are a lot of strategies here.
But at the end of the day, people complain that the agent is not following it.
And if you are following my argument, you can see why.
By the time a heavier harness gets to CLAUDE.md, you may have already given the agent a huge number of instructions that are not relevant to your project at all.
With Pi, my AGENTS.md is appended right into the system context. It is front and center. It is not sitting underneath a mountain of harness personality, tool procedure, orchestration rules, and default workflow assumptions.
So I do not run into the same level of the agent ignoring my instructions.
Occasionally, sure. These are still language models. They still drift.
But not nearly as much as people seem to complain about online.
The core argument
By the time you get to AGENTS.md or CLAUDE.md, you may have already lost some control over the agent if you are using one of the heavier harnesses.
Same thing if you install a plugin that tries to set everything up for you.
I am not saying you need to understand every single piece of your agent and harness at the implementation level.
What I am saying is this:
If you want a productive session with these agents, and if you want a productive environment for your team, you need to get a little closer to the meta.
You need to know what is being loaded.
You need to set your own system prompts.
You need to look at how MCP servers are loaded into your agent, and when they are loaded.
You need to look at which skills you are actually giving the agent.
You cannot just throw everything at it and hope more tools equals more intelligence.
A lot of the time, more tools just means more competing instructions.
What my own prompt is trying to do
In the interest of openness, my own system prompt is pretty straightforward.
It gives the agent a personality, because I like to have a little bit of fun while I work.
But the important part is that it gives the agent clear behavioral boundaries.
The instructions that follow are specific.
We write code in Go, Bun TypeScript, or Rust.
We care about functional style.
We care about composition.
We care about “you are not going to need it.”
I want the agent to think that way before it starts creating abstraction layers for imaginary future requirements.
I also noticed agents tend to drift into raw CSS or one-off styling habits if you let them. I can read that just fine, but it is not maintainable, even with talented engineers, and especially not with an agent that has no durable memory or real sense of project state.
So I force the styling approach.
Use Tailwind. Use UnoCSS. Use the project’s utility system. Put the utilities inline. Do not invent semantic class systems unless the project already works that way.
That kind of instruction matters because it shapes thousands of tiny decisions.
Split personal projects from work projects
I also have a very simple folder split between personal projects and work projects.
On my personal projects, the agent uses JJ instead of Git and commits as it goes.
That means I can go grab a cup of coffee and not worry about losing the experiment. Commits are cheap rollback points. The point is not pristine version control. The point is making sure the code does not disappear while we are exploring.
On work projects, it does not commit for me.
It does not freestyle Git history.
It follows whatever that work project already uses.
That is not complicated, but it is exactly the kind of thing I want the agent to know before it starts touching the repo.
Exploration rules matter too
After that, I tell it how to explore the codebase.
If you have used these agents, you know they immediately reach for grep, rg, or whatever search tool is available.
I think that is the wrong first move.
I do not care what the model providers say.
You need to orient yourself first.
So I tell the agent to use tree to get a map of the directory structure before it starts searching. Look at the shape of the project. Figure out whether this is an Astro site, a TypeScript app, a Go service, a Rust crate, a monorepo, whatever.
Then, once it is oriented, it can use rg, grep, find, or whatever more targeted search makes sense.
Otherwise, think about what is happening.
Before the first useful command, your agent may not actually know whether it is in a TypeScript project, a Rust project, a Go project, or something else.
Even if the answer is in your AGENTS.md, we have already established that the model might not follow that file reliably if the harness has buried it under too many other instructions.
So just tell it to check.
It sounds simple.
That is the point.
The boring rules are the ones that save the run
You probably have some version of these rules in your own AGENTS.md or CLAUDE.md already.
But if you are using a harness that tries to do everything for everyone, your instructions may be tacked onto the end of a long chain of contradictory, generic, and sometimes vibe-written defaults.
That is the part people underestimate.
They think the project file is the source of truth because it is the file they control.
But the model does not experience it that way.
The model experiences one giant context, with earlier instructions, tool descriptions, skills, server metadata, project rules, and user requests all competing for attention.
So the order and weight matter.
The shape of the harness matters.
The amount of preloaded workflow matters.
Why I like Pi for this
With something like Pi, I get control from day one.
I can append directly to the system prompt.
I can keep the harness small.
I can decide what skills are visible.
I can decide when external tools are loaded.
I can make the project rules front and center instead of hoping the model remembers them after reading a handbook worth of generic harness instructions.
That is the whole advantage.
It is not that Pi has the most features.
It is that Pi starts from less, so my instructions can matter more.
And for coding agents, that is a bigger deal than people think.
The takeaway
The harness is not neutral.
The system prompt is not decoration.
Skills are not weightless.
MCP servers are not free just because they are useful.
And your project rules may not have the authority you think they have if they are loaded too late or buried under too much harness behavior.
If you want better agent sessions, do not just ask which tool has the most features.
Ask what the model sees before it sees your work.
Ask how much of the context window is already spent.
Ask whether the agent is being guided by your rules, or by the generic workflow assumptions of the harness.
That is the meta layer.
And once you start paying attention to it, a lot of agent weirdness gets much easier to explain.
Thanks for coming to my TED Talk.