Idea: Route exact numeric questions through the Python tool

[undergroundrap]

Summary

Odysseus already has a real Python execution tool, and the tool index describes it as useful for computation, data processing, and math. The gap I noticed is that obvious numeric questions can still be answered directly by the model unless the user explicitly asks for tool use.

I think this is worth treating as foundational agent architecture: exact math should be computed, not guessed.

Why this matters

This is not just about calculator trivia. If users ask Odysseus to reason over budgets, invoices, nutrition logs, workout data, lab-style measurements, schedules, rates, percentages, or datasets, arithmetic mistakes become trust mistakes.

Better deterministic computation would make Odysseus more reliable for:

• personal finance and budgeting calculations;
• health, fitness, and nutrition tracking math;
• data analysis and statistics workflows;
• unit conversions, date math, percentages, and rates;
• any future dataset or spreadsheet-like workflows.

The model can still explain the result, but the numeric result itself should come from a tool path when possible.

Existing building blocks

From a quick scan, Odysseus already has most of the pieces:

• python tool exists and can execute real code;
• tool index already describes Python as useful for computation/math;
• chat-to-agent routing exists for calendar, notes, email, UI, research, and shell actions;
• I did not find an open issue or PR directly owning deterministic math/calculation routing.

So this may not require a large new system. The first version could be small and measurable.

Proposed direction

I would avoid a big calculator UI or broad symbolic-math feature at first. A narrow implementation could be:

1. Add focused examples/tests for obvious numeric prompts:

   • arithmetic;
   • percentages;
   • unit conversions;
   • date math;
   • simple aggregate stats.

2. Route those requests through deterministic computation when tools are available.

3. Return the computed result with a short explanation, making it clear that the number came from computation rather than model-only reasoning.

4. Keep unsafe or domain-specific advice separate. For example, compute the math accurately, but do not output unverified financial or medical advice.

Design considerations

A couple of tradeoffs seem important to handle up front:

• Latency: tool execution is slower than a direct model answer, so the first pass should only route clear exact-computation requests, not every message containing a number.
• Ambiguity: prompts like What is 15% of 85? are obvious candidates. Broader reasoning prompts should stay with the model unless an exact calculation is clearly needed.
• Safety: the computation layer should return numbers, not domain advice. For health or finance use cases, Odysseus can compute inputs more accurately while still avoiding medical/financial recommendations unless explicitly supported elsewhere.

Scope guard

I would not try to make the model “better at math” through prompting or fine-tuning here. The point is simpler:

• model decides/explains;
• tool computes;
• tests verify the routing and result shape.

Offer to help

I would like to lead the first focused implementation pass here, or at least help shape the foundational architecture so it fits Odysseus’s existing agent/tool-routing design.

I have worked on local-agent/data-analysis tooling where the main lesson was the same: models become much more useful when exact computation is routed through real Python/JS execution instead of being left to token prediction.

If maintainers are open to this direction, I can open a scoped issue with concrete repro examples and a test plan before writing the PR.