Writing
A place for essays and build notes about the operating habits behind good technical work.
Most people meet AI systems through prompt engineering. You give a model a task, useful context, and a clear output format. For one question, that can be enough. The design changes when the work keeps coming back. It crosses teams. It hits a bad source, a wrong tool, a missing permission, or a result that…
Most agent designs talk about creation. Real systems spend much of their life changing. You add a specialist. You move a public route. You split one overloaded role into two. You change the model profile. You discover that an old instruction caused a recurring failure. You replace a project layout that no longer fits the…
Agent systems become hard to trust when every important thing goes into the same place. Put all state in a chat and the system becomes difficult to inspect or rebuild. Put it all in a request ticket and the ticket turns into an unsafe archive. Put it all in source control and you start pretending…
One of the easiest mistakes in agent design is to treat every capable chat as a service. A chat can be thoughtful. It can have useful history. It can even complete a difficult task. None of that means another person or agent should depend on it as a standing part of an operating system. I…
When I say an agent system should learn, I do not mean the model is retraining itself or quietly rewriting its own rules. I mean organizational learning: a completed run captures what changed, someone reviews the pattern, an approved change improves instructions, tools, workflows, topology, or maintained knowledge, and the next run can benefit from…
It is tempting to treat AGENTS.md like a readme with a stronger name. That misses the point. In Codex, instruction files are read before work begins. They become part of the instruction chain that shapes how the task understands its job. The official Codex guide describes that chain as global guidance plus project files from…
Codex calls a conversation an agent. That is a useful product label, but it is not enough for a role that other people or agents need to rely on. For that job, I want a role with a clear purpose, an interface, the right project context, a current task identity, and a way to return…
When I built a multi-agent system that kept working across long-running jobs, the extra architecture solved real problems. It preserved ownership. It also gave results an explicit path back. Then the bill arrived. There were more endpoints to maintain, more state to inspect, and more callbacks to trace. A request could move correctly through the…
I once had a clean routing test make an agent system look finished. The request reached the right owner. Duplicate work was suppressed. The callback returned. Every mechanical check passed. The actual product had not run. No real source had been opened. No ordinary user had received a useful result. The test proved something important,…
“Publish this if it is safe” looks like a simple request. It is actually several requests hiding in one sentence. Someone must assess the evidence. Someone may recommend a decision. Someone may need to approve publication. Someone may have permission to make the change. If the system treats the prompt itself as permission, it can…
Imagine a long-running agent task losing contact halfway through a workflow. The easiest response is also the most dangerous: launch it again. The first worker might still have been running. It might have changed something before losing contact. A second attempt could repeat the same work, overwrite useful state, or send two answers. The real…