How Career-Ops Enforces the Hard Cap of 5 WebSearch Queries for Blocks D and G

Career-Ops enforces a strict hard cap of 5 WebSearch queries across Blocks D and G by defining a bounded research budget in modes/oferta.md that instructs the agent to stop early, avoid recursive tools, and validate compliance through automated tests.

The santifer/career-ops repository implements a strict research budget to prevent unbounded web scraping during job evaluations. When running in oferta mode (full A-G evaluation), the system limits online research to a maximum of five queries shared between compensation research in Block D and company legitimacy checks in Block G.

Where the 5-Query Hard Cap is Defined

The constraint originates in the mode definition file that governs full evaluations. In modes/oferta.md, lines 33-38 explicitly establish a bounded research budget that applies to both Block D (compensation-and-demand research) and Block G (legitimacy research).

The file declares that the agent must treat 5 total WebSearch queries as an absolute limit across these two blocks. This hard cap is not configurable per evaluation and applies regardless of how much evidence remains uncovered.

Operational Rules for the Research Budget

To maximize efficiency within the five-query allowance, modes/oferta.md (lines 34-38) mandates specific querying strategies:

• Prefer targeted queries that answer multiple questions simultaneously rather than issuing separate searches for each data point.
• Stop early when sufficient evidence has been gathered, even if the cap has not been reached.
• Never invoke recursive research tools such as deep-research or sub-agents that could bypass the explicit count.

These rules ensure the language model respects the budget as a strict resource constraint rather than a soft suggestion.

Behavior When the Cap is Reached

Once the agent exhausts the five-query allocation, specific fallback behaviors activate. According to lines 38-39 of modes/oferta.md, the system must:

1. Summarize the evidence found so far using only the data already retrieved.
2. Mark any missing data as unavailable rather than attempting additional searches.
3. Avoid any further WebSearch calls entirely, regardless of remaining questions in Blocks D or G.

This prevents the evaluation from stalling or silently exceeding the resource limit.

Validation Through Automated Testing

The repository validates this behavior programmatically. The file test-all.mjs contains assertions at lines 72-78 that verify:

• The mode text contains the explicit hard-cap clause.
• The implementation forbids additional queries beyond the fifth search.

These tests ensure that updates to the mode definitions do not accidentally remove the budget constraint.

Alternative for Deeper Research

If a user requires research beyond the five-query limit, Career-Ops provides an escape hatch without breaking the evaluation flow. Line 40 of modes/oferta.md instructs users to run a separate career-ops deep command after the initial evaluation completes.

This separation keeps the core evaluation fast and token-efficient while allowing extended research as an explicit additional step.

# Running a normal evaluation (oferta mode). The system will never issue

# more than 5 WebSearch queries across Block D and Block G.

career-ops evaluate --mode oferta "https://example.com/job/123"

# If you need more extensive research, run a separate deep-research step

# after the evaluation completes.

career-ops deep --url https://example.com/job/123

Code Implementation Example

The following pseudocode illustrates the query-budget check logic implemented in the system:

// Pseudocode illustrating the query-budget check
let webSearchCount = 0;
const HARD_CAP = 5;

async function runWebSearch(query) {
  if (webSearchCount >= HARD_CAP) {
    throw new Error('Research budget exhausted – no further WebSearch allowed');
  }
  webSearchCount++;
  return await actualWebSearch(query);
}

Key Files Implementing the Constraint

• modes/oferta.md – Defines the hard-cap and bounded research policy for Blocks D and G.
• test-all.mjs – Contains tests that assert the hard-cap clause is present and enforced.
• batch/batch-prompt.md – Mirrors the same budget constraints for batch processing workers.

Summary

Career-Ops enforces the hard cap of 5 WebSearch queries through a multi-layered approach:

• Declarative limits defined in modes/oferta.md (lines 33-38).
• Operational constraints that prohibit recursive tools and mandate early stopping.
• Graceful degradation that summarizes available evidence when the cap is reached.
• Automated validation via test-all.mjs (lines 72-78) to prevent regression.
• Architectural separation between fast evaluation and deep research via distinct commands.

Frequently Asked Questions

What happens when Career-Ops reaches the 5 WebSearch query limit during an evaluation?

When the limit is reached, the agent must summarize the evidence gathered so far, mark any missing data as unavailable, and avoid any further WebSearch calls. According to lines 38-39 of modes/oferta.md, the evaluation continues with existing data rather than failing or exceeding the budget.

Can I perform more than 5 WebSearch queries in a single Career-Ops evaluation?

No, the oferta mode enforces a hard cap of 5 total queries across Blocks D and G. If you require deeper research, you must run the separate career-ops deep command after the initial evaluation completes, as indicated in line 40 of modes/oferta.md.

How does Career-Ops prevent the agent from bypassing the query limit with recursive research?

The mode definition explicitly forbids recursive research tools. Lines 34-38 of modes/oferta.md instruct the agent to never invoke recursive research tools such as deep-research or sub-agents, ensuring the 5-query cap cannot be circumvented through delegation.

Is the 5-query limit tested automatically in the Career-Ops codebase?

Yes, the test-all.mjs file contains validation logic at lines 72-78 that checks the mode text for the hard-cap clause and verifies that the implementation forbids additional queries. This automated testing ensures the constraint remains enforced across code updates.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}