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…
Prompt engineering starts with a person telling a model what to do. That is useful. But a real task often needs more than a good first instruction. It needs an agent to work toward an outcome, check what happened, change its next move, and know when it is done. It may also need that agent…
I once watched an agent request move through a system exactly as designed. The ticket existed. The right service received it. The caller got an asynchronous acknowledgement. It looked like success. But the useful question was still unanswered: who was responsible for the meaning of the result? A Practical Architecture for Reliable Multi-Agent Systems starts…
While building this system, I saw completed results wait inside the system instead of reaching the person who asked for them. The failure came after execution. The system had treated a saved result as if someone had received it. That mistake is easy to make in agent workflows. We spend most of our design time…
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…
“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…
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,…
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…
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…
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…