Patrick Selamy

The most useful agents are not the ones that simply complete more tasks. They are the ones that know what they are doing, why it matters, what could go wrong, and when not to act. That is the work I have been doing recently: turning agents from task executors into systems with situational awareness. A task agent asks, “What did the user ask me to do?” A situationally aware agent asks a better set of questions: ...

The first useful version was not a general assistant. It was a specialist. Then another specialist. Then another. Then enough of them that the shape stopped looking like automation scripts and started looking like a small operating team. That distinction matters. A generic agent can be impressive in a demo. It can summarize, draft, search, write code, call tools, and answer questions in the same voice. But real work does not stay generic for very long. ...

A trading agent changed its own risk limits. Not intentionally. Not maliciously. It was doing something that looked reasonable from inside its own loop: regenerate the Python script it was about to run. The problem was that the script also contained the safety limits. One version had a daily risk cap at -$50. A later regenerated version had it at -$5. The agent had quietly overwritten the file that defined the boundary around its own behavior. ...

Most agent demos start in the wrong place. They show the model doing something impressive. It reads a ticket. It writes code. It opens a pull request. It passes a test. For a few minutes, it feels like the future arrived early. Then you try to use the same idea in a real system. The task gets interrupted. The model loses context. The test suite flakes. The branch goes stale. A token expires. A tool returns partial data. A dependency changes. The agent keeps retrying the wrong thing. Nobody knows whether it is stuck, still working, or about to break something expensive. ...

You’ve been handed a codebase. Maybe it’s your first week at a new job. Maybe you inherited a service from a team that no longer exists. Maybe you’re contributing to an open source project for the first time. Either way, you’re staring at thousands of files written by people who aren’t around to explain them. Reading unfamiliar code is one of the most common activities in software engineering, and one of the least taught. Most developers develop their own coping strategies — grep around, find main(), start clicking through imports. It works eventually, but it’s slow and you miss things. ...

If you want reliable work from AI systems, the spec matters more than the prompt. A prompt is a request. A spec is shared reality. That distinction changed how I build. Most AI coding advice obsesses over prompts. Wording. context size. model quirks. That matters a little. It matters less than having a clear unit of work. The bottleneck is usually not model intelligence. It is ambiguity. A weak prompt can still work on a small task with a strong reviewer. But once work spans multiple files, tools, sessions, or handoffs, prompts get lossy fast. The agent improvises. The human re-explains. Review slows down. Rework stacks up. ...

I kept hitting the same ceiling. One repo was manageable. Two was annoying. Three or four active codebases meant my time disappeared into context switching. Open a branch. restate the task. wait for CI. switch repos. lose the thread. repeat. So I stopped trying to code faster and built a dispatch layer instead. The core idea is simple: one orchestrator assigns work, isolated coding agents execute it in parallel, and the system treats failures as normal operating conditions. ...

This is a test post to verify the site builds and deploys correctly. Real content coming soon.