Teach Your Harness What to Forget

In the previous article we talked about the basics of how to customize your instructions, skills and hooks, and what they are useful for.

If you followed my guidance and did set up the Lessons instruction and worked on the project, you probably have some amount of Lessons as well next to the Memories.
This is great, the content loaded directly into your context is a short listed format, however this can still grow big.
I personally easily did create 1.4 entries per day, which can overly fill your context.

Your Lessons Are Costing You Context

Now let’s see how to tackle this situation and improve the cost-value ratio.

Continue reading Teach Your Harness What to Forget

How a Model Eval Turned out Agent Contract Refinement


Small Models Are Prompt Linters: How a Model Eval Turned out as an Agent Contract Refinement Exercise


I ran a five-model comparison to find out which model could drive my planner agent of my Forge agentic pipeline. I got back a code review of my prompt.

My /forge pipeline starts with a planner agent. It interviews me, sends researchers into the codebase, and writes a plan.md that the coder agent implements without re-exploring anything. It had run on a frontier model since I built it, and I wanted to know whether a local model could take that seat. The planner is the most expensive stage, and it runs first, so every token it burns is spent before I know the task was worth doing.

So: a one-shot simple prompt, 4 models adn the pipeline. A frontier reference (Sonnet 5) plus three open-weight models I can host (qwen3.5-122b-a10b, qwen3.6-35b-a3b, qwen3.6-27b), producing plans, scored on contract compliance, grounding, hazard coverage, executability and consistency.

I got the ranking I wanted. I also got something I hadn’t gone looking for: a defect list for my own agent definition.

Continue reading How a Model Eval Turned out Agent Contract Refinement

Token Efficiency for LLM assisted Development

How seven load-bearing principles across chat sessions and agentic pipelines, keep LLM dev costs manageable without degrading what the tools produce.

Occasinally I had a problem most people working with LLMs eventually run into: Long sessions forgot their own constraints. Multi-file investigations dumped thousands of tokens into the main context and never gave them back. Pipelines paid full price for content that should have been cached. None of it was the model’s fault, all of it needs only changing how you worked with the tools. The patterns below come experience and research about LLM assisted development to scale. Design choices about where to spend tokens and where not to.

One-line thesis: token efficiency is a design discipline, effectivness not being cheap.


Continue reading Token Efficiency for LLM assisted Development

Building an Agentic Dev Pipeline — From Ad-Hoc Prompting to a Repeatable Protocol

How eleven design decisions, a structured interview technique, and two effectiveness axes turned a slash command into a self-managing dev loop.

I had a problem that most people using LLMs for development eventually hit: inconsistency. Sometimes I’d get well-structured code with tests. Sometimes I’d get a half-finished implementation with no tests and no explanation of what changed. Sometimes I’d ask the same question twice and get architecturally different answers. The issue wasn’t the model — it was me. Every session started from scratch. No shared protocol. No handoffs. Just vibes.

The pipeline I built this week replaces that. It’s not a framework or a library — it’s nine files that define a protocol: who does what, in what order, with what information, and when to ask me before proceeding. The output is repeatable. The quality is auditable. And the design decisions that shaped it contain, I think, some generally useful lessons about building agentic systems.

One-line thesis: a well-designed agentic pipeline is a protocol, not a prompt.

Continue reading Building an Agentic Dev Pipeline — From Ad-Hoc Prompting to a Repeatable Protocol