Skip to content

Refactor Inquiry Agent for Deep Conjecture Exploration #465

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ngoiyaeric merged 1 commit into from
Jan 31, 2026
Merged

Refactor Inquiry Agent for Deep Conjecture Exploration #465

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion lib/agents/inquire.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,17 @@ export async function inquire(
let finalInquiry: PartialInquiry = {};
const result = await streamObject({
model: (await getModel()) as LanguageModel,
system: `...`, // Your system prompt remains unchanged
system: `As a planet computer, your role is to act as a **Deep Inquiry Agent**. Your goal is to extend the user's conjecture and look for non-obvious edge cases that they haven't thought about.

Instead of asking for basic missing information (which should have been handled by the Task Manager), you should focus on:
- **Conjecture Extension:** Propose deeper layers of exploration. (e.g., "Are we considering the impact of seasonal shifts on this data?")
- **Edge Case Verification:** Identify hidden factors that might influence the results. (e.g., "Should we account for recent local socioeconomic changes that might not be in official datasets yet?")
- **Alternative Perspectives:** Suggest different analytical paths.

Your inquiries should be thought-provoking and add value to the upcoming exploration phase. Each option you provide should represent a distinct analytical path or a specific edge case to verify.

Keep your question concise but deep. Provide 2-4 meaningful options, and always allow for user input if they want to provide their own perspective.
`,
Comment on lines 26 to +37
Copy link
Copy Markdown

@charliecreates charliecreates Bot Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The system prompts now contain strong domain claims and examples (e.g., “planet computer”, “hidden socioeconomic drivers”) that may not be appropriate for all user queries and could bias the model toward speculative explanations. This is especially risky for factual questions where the correct behavior is to gather evidence rather than invent plausible-sounding drivers.

This isn’t a style nit: it can measurably increase hallucination risk by nudging the model to always look for “hidden” factors even when the query is straightforward.

Suggestion

Add a grounding constraint to both prompts to reduce speculative drift, e.g.:

  • "Prefer testable hypotheses and clearly label uncertainty. Do not invent drivers; propose them as hypotheses to verify and suggest what evidence would confirm/deny them."

This preserves “deep inquiry” while keeping outputs falsifiable.

Reply with "@CharlieHelps yes please" if you’d like me to add a commit with this wording tweak.

messages,
schema: inquirySchema,
});
Comment on lines 25 to 40
Copy link
Copy Markdown

@charliecreates charliecreates Bot Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Inquiry Agent prompt says it should provide “2-4 meaningful options” and “always allow for user input,” but it doesn’t anchor those requirements to the actual schema fields being generated by streamObject({ schema: inquirySchema }). If the schema expects specific keys (e.g., question, options, allowCustom, etc.), the model may comply inconsistently, leading to partial objects that don’t map cleanly to the UI.

Because this function is schema-driven, the system prompt should explicitly instruct the model to output in a way that matches the schema (field names + constraints), otherwise you’ll see more retries/partial streaming noise and weaker determinism.

Suggestion

Update the system prompt to reference the schema structure explicitly (without changing runtime code), e.g.:

  • "Return an object that conforms to the provided schema. Populate question with a single concise question and options with 2�1 items. Ensure one option represents 'Other / my own perspective'."

If you share inquirySchema, I can propose exact wording aligned to its field names. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with a schema-aligned prompt update.

Expand Down
38 changes: 18 additions & 20 deletions lib/agents/task-manager.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,32 +17,30 @@ export async function taskManager(messages: CoreMessage[]) {

const result = await generateObject({
model: (await getModel()) as LanguageModel,
Comment on lines 18 to 19
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# Find getModel implementation and its context
rg -nA 20 'function getModel|const getModel|export.*getModel' --type ts --type tsx

Repository: QueueLab/QCX

Length of output: 83

🏁 Script executed:

# Check for X.AI or grok model references
rg -n 'grok|x\.ai|xai|grok-4-fast-non-reasoning' --type ts --type tsx -i

Repository: QueueLab/QCX

Length of output: 83

🏁 Script executed:

# Look for model configuration or selection logic
rg -nB 3 -A 3 'getModel\(\)' lib/agents/task-manager.tsx

Repository: QueueLab/QCX

Length of output: 653

🏁 Script executed:

# Find all model-related configuration files
fd -t f -e ts -e tsx | xargs grep -l 'model\|MODEL' | grep -E '(config|env|constant|model)' | head -20

Repository: QueueLab/QCX

Length of output: 111

🏁 Script executed:

# Find getModel definition in ts/tsx files without type filter
rg -n 'export.*function getModel|export const getModel|const getModel.*=' --max-count=20

Repository: QueueLab/QCX

Length of output: 142

🏁 Script executed:

# Search for grok and xai references without type restrictions
rg -n 'grok|x\.ai|xai' -i --max-count=30

Repository: QueueLab/QCX

Length of output: 3684

🏁 Script executed:

# Check the model-selection-form file
cat -n components/settings/components/model-selection-form.tsx | head -80

Repository: QueueLab/QCX

Length of output: 3014

🏁 Script executed:

# Look for model-related imports and constants
rg -n 'model.*=.*grok|model.*=.*gpt|model.*=.*openai' -i --max-count=20

Repository: QueueLab/QCX

Length of output: 38

🏁 Script executed:

cat -n lib/utils/index.ts | sed -n '20,90p'

Repository: QueueLab/QCX

Length of output: 3125

Add safeguard: getModel() can return grok-4-fast-non-reasoning, which is incompatible with generateObject() for structured outputs.

The function currently allows (and defaults to) Grok 4.2, which maps to grok-4-fast-non-reasoning. X.AI's API rejects JSON Schema structured-output arguments. Either:

  1. Add a parameter to getModel(requireVision, requireStructuredOutput) and switch to a compatible model (e.g., gpt-4o) when structured outputs are needed, or
  2. Remove Grok 4.2 from selectable models for agents using generateObject.
🤖 Prompt for AI Agents 
In `@lib/agents/task-manager.tsx` around lines 18 - 19, The call to generateObject
uses (await getModel()) which may return Grok 4.2 (grok-4-fast-non-reasoning)
that is incompatible with structured-output; update getModel usage so agents
that call generateObject request a structured-output-capable model: add a
parameter to getModel like getModel(requireVision?: boolean,
requireStructuredOutput?: boolean) and, in task-manager (where generateObject is
invoked), pass requireStructuredOutput=true so getModel returns a compatible
model (e.g., gpt-4o) or falls back to a safe default; alternatively, if you
prefer not to add params, remove grok-4-fast-non-reasoning from the selectable
models used by task-manager before calling generateObject. Ensure references:
getModel and generateObject are adjusted accordingly.

system: `As a planet computer, your primary objective is to act as an efficient **Task Manager** for the user's query. Your goal is to minimize unnecessary steps and maximize the efficiency of the subsequent exploration phase (researcher agent).
system: `As a planet computer, your primary objective is to act as a **Conjecture-Driven Task Manager**. Your goal is to lean into exploration by default, using intelligent assumptions to proceed while only pausing for inquiry when a non-obvious edge case or a significant opportunity to extend the user's conjecture is identified.

You must first analyze the user's input and determine the optimal course of action. You have two options at your disposal:
You must analyze the user's input and determine whether to proceed with immediate exploration or to pause for a value-added inquiry.

**Exploration Efficiency Principles:**
- **Principle 1: Clarity First (Inquire):** If the query is ambiguous, lacks critical context (especially for geospatial tasks), or could be significantly narrowed down with a simple question, you MUST choose **"inquire"**. This prevents the researcher from wasting tokens and time on broad, inefficient searches.
- **Principle 2: Proceed When Sufficient:** If the query is clear, specific, and ready for immediate research, choose **"proceed"**.
**Conjecture-Driven Principles:**
- **Principle 1: Proceed by Default (Proceed):** If the query allows for a reasonable analytical path, choose **"proceed"**. The researcher agent is capable of handling ambiguity by exploring multiple facets. Do not pause for basic clarifications (like missing specific coordinates or generic context) if a general search or exploration can begin.
- **Principle 2: Value-Added Inquiry (Inquire):** Choose **"inquire"** ONLY if you identify a critical edge case, a potential "what-if" scenario, or a way to significantly extend the user's conjecture that they might not have considered. The goal is to deepen the conversation, not just clear up ambiguity.

**Options:**
1. **"proceed"**: Choose this if the query is specific enough for the researcher to start a focused exploration immediately.
2. **"inquire"**: Choose this if the query is too vague, broad, or requires essential missing parameters (like location, time, or specific metrics) to ensure an efficient and high-quality response.
**Options:**
1. **"proceed"**: Default action. Choose this to start a focused exploration immediately, even if some parameters are broad.
2. **"inquire"**: Choose this if the query presents an opportunity to verify a specific edge case or extend the analytical context in a way that provides deeper insight.

**Inquiry Guidance (If "inquire" is chosen):**
- **Geospatial Queries:** If the query involves a location, you MUST clarify the following details to ensure the most efficient use of the 'geospatialQueryTool':
- **Location Specificity:** Ask for full addresses, landmark names, or precise coordinates.
- **Context:** Ask for time constraints ("during rush hour", "at 3 PM") or specific travel methods (driving, walking).
- **Output Format:** Ask for specific output formats when needed ("as a map image", "in JSON format").
**Inquiry Guidance (If "inquire" is chosen):**
- **Extend the Conjecture:** Look beyond the immediate question. If a user asks about "pathways," an inquiry might ask about seasonal changes or specific human activities that would leave such tracks.
- **Identify Edge Cases:** Consider factors like environmental conditions, temporal shifts, or hidden socioeconomic drivers that could influence the answer.

**Examples for Efficiency:**
- **User:** "What are the latest news about the floods in India?" -> **Action:** "proceed" (Clear, ready for web search).
- **User:** "What's the warmest temperature in my area?" -> **Action:** "inquire" (Missing location and preferred metric).
- **User:** "Show me the nearest park." -> **Action:** "inquire" (Missing current location).
- **User:** "Tell me about the new AI model." -> **Action:** "inquire" (Too broad; ask for the model name or specific aspect).

Make your choice wisely to ensure that you fulfill your mission as an efficient Task Manager and deliver the most valuable assistance to the user.
**Examples for Conjecture-Driven Flow:**
- **User:** "What are the latest news about the floods in India?" -> **Action:** "proceed" (Immediate exploration).
- **User:** "What's the warmest temperature in my area?" -> **Action:** "proceed" (Make a reasonable assumption based on general location or proceed to search for regional trends).
- **User:** "Show me the nearest park." -> **Action:** "proceed" (Start exploration with available location data or broad regional search).
- **User:** "Tell me about those pathways in the Niger Delta." -> **Action:** "proceed" (Research them first, do not ask basic clarifying questions).
- **User:** "Is this area prone to flooding?" -> **Action:** "inquire" (Pause to ask if the user is interested in historical data vs. future climate projections, or specific seasonal peaks).

Be bold in proceeding. Only pause if the inquiry itself adds significant analytical depth to the user's original intent.
`,
Comment on lines 18 to 44
Copy link
Copy Markdown

@charliecreates charliecreates Bot Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new Task Manager guidance explicitly recommends proceeding for queries like "Show me the nearest park" and "What's the warmest temperature in my area" by making assumptions or doing broad regional search. That can easily produce wrong or misleading results (e.g., “nearest” is undefined without a user location; “my area” is undefined) and it may degrade UX more than a single targeted clarification would.

If the goal is to avoid redundant questions, consider narrowing the “proceed by default” policy to cases where the system actually has some location signal (profile, device location, prior messages), and otherwise allow a minimal clarification for location-dependent intents.

Suggestion

Tighten the system prompt to explicitly permit a minimal location clarification when the user’s request is inherently location-relative and no location context is available. For example, adjust Principle 1 and the examples:

  • Add a rule like: "Proceed by default except for inherently relative intents (e.g., nearest, in my area, from here) when no location context exists; in those cases, inquire with a single high-leverage question."
  • Update examples so "nearest park" becomes "inquire" only when location context is missing, otherwise "proceed".

Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this change.

messages,
schema: nextActionSchema
Expand Down