Put the math in code, the judgment in the spec
When you build an agentic tool, split the work by one question: does this step have a single correct output? If yes, write code. If no, write a spec the agent reads.
I have a tool that picks and manages long-dated SPY call options. The split falls out cleanly.
The numbers have one right answer, so they live in Python. One script fetches the chain and computes a delta for every contract; another applies the hard filters:
calls = calls[calls["dte"] >= 365]
calls = calls[(calls["delta"] >= 0.70) & (calls["delta"] <= 0.85)]
calls = calls[calls["openInterest"] >= 500]
calls["spread_pct"] = (calls["ask"] - calls["bid"]) / calls["mid"]
calls = calls[calls["spread_pct"] <= 0.10]
There is exactly one set of survivors. Never make a model do float math it can get wrong.
The judgment has no right answer, so it lives in prose the agent reads at startup:
- Flag if implied vol is in the top decile vs. neighboring strikes.
- Report one primary pick plus one alternative.
- If nothing clears the filters, say so. Don't recommend a marginal pick.
These need explanation, escalation, and presentation. Freeze them into a filter and you lose the part a person actually wanted.
Each workflow is a slash command that wires the two halves together, and the split shows up in what each command is allowed to do. /update-chain only runs the fetcher. It's pure code with no judgment, so it's told to refresh the data and explicitly not rank or recommend. /leap-pick runs the fetcher, applies the filters, then hands the survivors to the spec to rank and explain. /analyze-holdings marks my open positions to market off the same chain. The command file is the spec. It says what to do and which guardrails hold, like don't pivot to puts and don't recommend a marginal pick. The scripts underneath do the arithmetic, and the agent just decides which command the moment calls for.
The rule: single correct output goes in code; "it depends" goes in the spec. The agent is the orchestrator, not the calculator.