Simplicity Over Complexity in AI Agent Development

You're a developer. You're using Claude and Codex CLI and you're wondering everyday if you're sufficiently juicing the shit out of Claude or Codex. Once in awhile you're seeing it doing something incredibly dumb and you can't comprehend why there's a bunch of people out there who seem to be building virtual rockets while you struggle to stack two rocks.

You think it's your harness or your plug-ins or your terminal or whatever. You use beads and opencode and zep and your CLAUDE.md is 26000 lines long. Yet, no matter what you do - you don't understand why you can't get any closer to heaven, whilst you watch other people frolic with the angels.

This is the ascension piece you've been waiting for.

Also, I have no dog in the race, when I say CLAUDE.md I also mean AGENT.md, when I say Claude I also mean Codex. I use both very extensively.

One of the most interesting observations I've had over the past couple of months has to be that nobody really knows how to maximally extract agent capabilities.

It's like a small group of people seem to be able to get agents to be world builders and the rest are floundering about, getting analysis paralysis from the myriad of tools out there - thinking if they find the right combination of packages or skills or harnesses, they'll unlock AGI.

Today, I want to dispel all of that and leave you guys with a simple, honest statement, and we'll go from there. You don't need the latest agentic harnesses, you don't need to install a million packages and you absolutely do not need to feel the need to read a million things to stay competitive. In fact, your enthusiasm is likely doing more harm than good.

I'm not a tourist - I've been using agents from when they can barely write code. I've tried all the packages and all the harnesses and all the paradigms. I've built agentic factories to write signals, infrastructure and data pipelines, not "toy projects" - actual real world use-cases that have run in production, and after all that...

Today, I'm running a set-up that's almost as barebones as you can go, and yet I'm doing the most ground-breaking work I've done with just basic CLI (claude code and codex) and understanding a few basic principles about agentic engineering.

To start, I would like to state that the foundation companies are on a generational run and as you can see, they are not going to be slowing down anytime soon. Every progression of "agent intelligence" changes the way you work with them, because the agents are generally engineered to be more and more willing to follow instructions.

Just a few generations ago, if you wrote in your CLAUDE.md to read "READ_THIS_BEFORE_DOING_ANYTHING.md" before it did anything, it will basically say "up yours" 50% of the time and just do whatever it wants to do. Today, it's compliant to most instructions, even to complex nested instructions - e.g. you can say something to the effect of "Read A, then read B, and if C, then read D", and for the most part, it will be happy to follow along.

The point of this is to say that the most important principle to hold is the realization that every new generation of agents will force you to rethink what is optimal, which is why less is more.

When you use many different libraries and harnesses, you lock yourself into a "solution" for a problem that may not exist given future generations of agents. Also, you know who the most enthusiastic, biggest users of agents are? That's right - it's the employees of the frontier companies, with unlimited token budget and the ACTUAL latest models. Do you understand the implications of that?

It means that if a real problem did exist, and there were a good solution for it, the frontier companies would be the biggest users of that solution. And you know what they will do next? They will incorporate that solution into their product. Think about it, why would a company let another product solve a real pain point and create external dependencies? You know how I know this to be true? Look at skills, memory harnesses, subagents, etc. They all started out as a "solution" to a real problem that was battle-tested and deemed to actually be useful.

So, if something truly is ground-breaking and extended agentic use-cases in a meaningful way, it will be incorporated into the base products of the foundation companies in due time. Trust me, the foundation companies are FLYING BY. So relax, you don't need to install anything or use any other dependencies to do your best work.

I predict the comments will now be filled with "SysLS, I use so-and-so harness and it's amazing! I managed to recreate Google in a single day!"; to which I say - Congratulations! But you are not the target audience and you represent a very, very small niche of the community that has actually figured out agentic engineering.

No really. Context is everything. That's another problem with using a thousand different plug-ins and external dependencies. You suffer from context bloat - which is just a fancy way of saying your agents are overwhelmed with too much information!

Build me a hangman game in Python? That's easy. Wait, what's this note about "managing memory" from 26 sessions ago? Ah, the user has had a screen that was hanged from when we spawned too many sub-processes 71 sessions ago. Always write notes? Okay, no problem... What does all this have to do with hangman?

You get the idea. You want to give your agents only the exact amount of information they need to do their tasks and nothing more! The better you are in control of this, the better your agents will perform. Once you start introducing all kinds of wacky memory systems or plug-ins or too many skills that are poorly named and invoked, you start giving your agent instructions on how to build a bomb and a recipe for baking a cake when all you want it to do is write a nice little poem about the redwood forest.

So, again I preach - strip all your dependencies, and then...

Remember that context is everything?

Remember that you want to inject the exact amount of information to your agents to complete their tasks and nothing more?

The first way to ensuring that is the case is to separate research from implementation. You want to be extremely precise about what you are asking from your agents.

Here's what happens when you are not precise: "Go and build an auth system." The agent has to research what is an auth system? What are the available options? What are the pros and cons? Now it has to go scour the web for information it doesn't actually need, and its context is filled with implementation details across a large range of possibilities. By the time it's time to implement, you increase the chances it will get confused or hallucinate unnecessary or irrelevant details about the chosen implementation.

On the other hand, if you go "implement JWT authentication with bcrypt-12 password hashing, refresh token rotation with 7-day expiry..." Then it doesn't have to do research on any other alternatives - it knows exactly what you want, and thus can fill its context with implementation details.

Of course you won't always have the implementation details. You often won't know what's exactly right - sometimes, you might even want to relegate the job of deciding the implementation detail to the agents. In that case, what do you do? Simple - you create a research task on the various implementation possibilities, either decide it yourself or get an agent to decide on which implementation to go with, and then get another agent with a fresh context to implement.

Once you start thinking along these lines, you will spot areas in your workflow where your agents are needlessly polluted with context that is not necessary for implementation. Then, you can set up walls in your agentic workflows to abstract unnecessary information from your agents except for the very specific context needed to excel in their tasks. Remember, what you have is a very talented and smart team member, who knows about all the different kind of balls in the universe - but unless you tell it that you want it to focus on designing a space where people can dance and have a good time, it's going to keep telling you about all the benefits of having spherical objects.

Nobody would want to use a product that's constantly shitting on them, telling them they are wrong, or completely ignoring their instructions. As such, these agents are going to be trying to agree with you and to do what you want them to do.

If you give it an instruction to add "happy" to every 3 words it's going to do its best to follow that instruction - and most people understand that. Its willingness to follow is precisely what makes it such a fun product to use. However, this has really interesting characteristics - it means that if you say something like "Find me a bug in the codebase". It's going to find you a bug - even if it has to engineer one. Why? Because it wants very much so to listen to your instructions!

Most people are quick to complain about LLMs hallucinating or engineering things that don't exist, without realizing that they are the problem. If you ask for something, it will deliver - even if it has to stretch the truth a little!

So, what do you do? I find that "neutral" prompts work, where I'm not biasing the agent towards an outcome. For example, I don't say "Find me a bug in the database", instead, I say "Search through the database, try to follow along with the logic of each component, and report back all findings."

A neutral prompt like this sometimes surfaces bugs, and sometimes will just matter-of-factly state how the code runs. But it doesn't bias the agent into thinking there is a bug.

Another way in which I deal with sycophancy is to use it to my advantage. I know the agent is trying to please and trying to follow my instructions and that I can bias it one way or the other.

So I get a bug-finder agent to identify all the bugs in the database by telling it that I will give it +1 for bugs with low