| You can phrase the job as “Given X, produce Y” in one shot | ✅ Best fit | ⚠️ Overkill | Magic functions are optimized for single, stateless transforms. |
| Each input item is independent (batches, lists, records) | ✅ Best fit | ❌ Not appropriate | No cross-item memory needed; agent state adds no benefit. |
| You need to keep and reuse context across multiple steps | ❌ Loses context each call | ✅ Best fit | Agents maintain conversation and REPL history. |
| Later steps depend tightly on earlier AI outputs | ⚠️ Must manually pass everything back in | ✅ Best fit | With agents, the prior reasoning is “already in the room.” |
| The workflow is conversational or exploratory | ❌ Awkward (you’d simulate a chat) | ✅ Best fit | Agents are built for back-and-forth refinement. |
| You want strict, predictable “pure function” behavior | ✅ Best fit | ⚠️ Possible but harder to reason about | Stateless calls are easier to test, debug, and cache. |
| You want the AI to orchestrate tools over time (plan → act → adjust) | ⚠️ Only for simple tool calls | ✅ Best fit | Agents shine in multi-step orchestration loops. |
| You need to run at scale (thousands of similar calls) | ✅ Best fit | ❌ Expensive & complex | Stateless calls parallelize and scale horizontally. |
| You have strict latency or cost budgets per operation | ✅ Typically cheaper, more predictable | ⚠️ Higher overhead | Agent state and multiple turns increase cost/latency. |
| You’re integrating into an existing pipeline as a “smart function” | ✅ Natural drop-in | ⚠️ Integration overhead | Magic functions look like any other function; agents introduce sessions. |
| You need to inspect / audit behavior per call | ✅ Narrow, local reasoning | ⚠️ State makes it harder to replay | Stateless calls are easier to log and replay in isolation. |