Why I combined fetching and extraction in one agent tool

I’ve been building a lead-generation agent with the OpenAI Agents SDK and ZenRows. It takes a plain-language ICP and a directory URL, extracts companies, checks their websites, and returns a ranked JSON list with a score and reasoning. The first version exposed fetching and extraction as separate agent tools. That failed on a real directory page because the fetched Markdown was about 540K characters. Passing it from fetch_page into extract_leads meant putting the entire document into the model context, which caused a context overflow. I combined those steps into one tool: discover_leads = fetch page → extract companies → return compact Lead records The model receives the records, not the full page. Enrichment and scoring had a similar issue. Website excerpts were large enough that the model started summarizing them before scoring, so I moved those steps into a second tool: qualify_lead = enrich one lead → score it → return reasoning The four underlying functions still exist and can be tested independently. Large intermediate results stay in Python, and a failed enrichment can retry a single lead without restarting the run. A few other changes helped: A 429 returns a retry instruction, while a 403 tells the agent not to retry. One bad URL no longer ends the entire run. The agent follows a fixed sequence: discover, qualify leads with websites, sort, and return. On one Clutch page, the pipeline extracted 78 companies and scored the first 10 in under 20 seconds each. The reasoning was more useful than the score because it showed what evidence was missing, such as case studies without named clients. For multi-step agents, where do you draw the line between model orchestration and deterministic code? How much of the workflow should the model control once the data-processing steps are reliable?