Strategic Ignorance

Let's talk about ignorance. Strategic ignorance, to be precise. What could that mean? It means tuning your information pipelines so that your agents forget, or never know in the first place. I have talked a lot about context, and about the value of providing broad context. It is worth being more nuanced.

Case in point. I am excited to collaborate with the folks who are leaning into methods associated with probabilistic compute: eval-based, test-driven, measured experiments, especially in sales and marketing. To get agents to perform, these methods are essential. They give you empirical signal, and well-structured loops for improvement are quickly becoming best practice rather than a fringe idea.

The part that is getting under-planned

Agent and chain isolation. So the context bleeds, the experiments are not clean, and what you get is reversion to the mean.

When you are designing loops and agents to do work, to self-improve, to manage their own context frames, do not forget to make them forget. Keep them isolated, so you do not end up with something that kind of works by accident instead of a system that continuously improves on purpose.

The same goes for the SDLC

The agentic SDLC, I should say. If the same agent is writing your requirements, doing your research, reading your codebase, building your prototype, and implementing all of it, you are liable to get an agent that does a half-baked job at every one of them.

Separate them. Give each one a purpose, context that is generalized but specific, meaning, and the artifacts it needs to do the work you are hiring it for. You get better results, and, more to the point, you can measure the difference instead of hoping for it.

Please do not do this in a plugin. Do not do it with a pile of skills.

The context always bleeds together. Orchestrate these things outside your harness. Move the contexts that are permanent to an outside store, read them, manage them, but do not bias them on the first pass. Let them be, before you mash them all together in some consensus party. What is the point of that? Design by committee leads nowhere good. Information and knowledge architectures are a different animal.

Design your ontology with purpose

Wire it together with intent, and keep your agents far away until they need to do a thing. The alternative is dealing with the slop and the token-maxing.

None of this is a rejection of context. It is the opposite. It is taking context seriously enough to govern it: to decide what an agent sees, when it sees it, and why, and to keep a clean record of it outside the agent that consumed it. That is the case my co-authors and I made formally in our paper, and it is the same argument I keep making, that governing the interaction matters more than the agent on top.

Not less context. Better context. At the right time, for the right purpose. Isolation drives clarity, and clarity drives results.