How the assistant is bounded

Flux Intelligence is genuinely agentic: it decides what to retrieve, calls a tool, reads the result, and calls another until it can answer or reaches its limit.

It is also incapable of changing anything. Both statements are true, and the combination is the design.

The tool boundary #

The model never receives a database connection, credentials, or the ability to write a query. It can invoke only a fixed catalogue of bounded, authenticated, read-only tools — the same ones behind the product’s own reports.

Available	Not available
Governed report catalogue	Raw SQL execution
Cost summary and charge-level evidence	Direct database access
Cost-change investigation	Cloud credentials
Anomalies with contributors	Any write, resize, delete, or purchase
Fleet telemetry and right-sizing findings	Arbitrary HTTP requests
Inventory, opportunities, policy posture	Access to another tenant’s data

Requests carrying SQL-shaped arguments are rejected before execution. This is enforced at the tool layer, not by instructing the model to behave.

Autonomous about looking, powerless to act #

The agent can chain a dozen governed reads to chase a cost spike across subscriptions, services, and charge-level evidence, without being told how.

It cannot resize a machine, buy a commitment, edit a tag, or write a byte — not because policy discourages it, but because no such tool exists for it to call. There is no path from the assistant to a mutation, so there is nothing to bypass.

The AI narrates; it does not calculate #

The numbers the assistant reports come from deterministic engines — anomaly baselines, right-sizing rules, allocation, valuation. Those are statistics and rules, versioned and tested.

The agent retrieves those results and explains them. It is never the thing computing the figure you act on.

This is why Flux does not describe its analysis as AI-powered. The analysis is arithmetic; the AI is the interface to it.

What it must refuse #

Where Flux has no deterministic engine, the assistant is required to say so rather than improvise.

The clearest example is commitment purchase planning. Asked to build a reservation plan with quantities, terms, scope, and break-even, the assistant will report what it can — coverage, utilization, right-sizing evidence — and state plainly that Flux has no governed commitment-planning engine, instead of producing a confident purchase plan from arithmetic done inside a language model.

Similarly, target SKUs for right-sizing come only from the governed recommendation engine. The assistant will not select a replacement SKU itself.

Operating limits #

Limit	Purpose
Tool-call ceiling	Bounds cost and latency per conversation
Spend ceiling	Hard stop below the configured budget
Input limit	Bounds conversation size
Role requirement	Same application role as the rest of the product
Response contract	Replies validated against a strict schema
Quality scoring	Every reply scored deterministically

Fleet-scale questions are served by tools that return many resources per call, so an estate-wide question resolves in a handful of steps rather than exhausting the budget one resource at a time.

Quality review #

Each reply is scored on structure, grounding, partial-coverage disclosure, table formatting, and completeness. Administrators can review transcripts and scores, so answer quality is a tracked metric rather than an impression.

Model reasoning is never retained — only the prompt and the validated reply.