By Neil Kumar, Director of Product
Somewhere in your stack, something is deciding how hard your agents are allowed to work. Maybe it’s a concurrency ceiling your platform team set on purpose. More likely, it’s a billing threshold that suspends compute when cost crosses a line, set by someone in finance who has never read one of your agents’ queries.
This is the third post in a series on what agentic analytics does to the data platform underneath it. In The Modal Tax, I argued that agents break the best-of-breed stack. Integration that used to be built once and reused now gets rebuilt in every reasoning loop, and every boundary an agent crosses is paid for live, in tokens, accuracy, latency, and scratch state. In The Threshold Question, I looked at when architecture starts to matter at all. It stays invisible while cache absorbs the workload, and agents push teams past that point faster than they expect, because their queries are exploratory, continuous, and write-heavy.
Both posts kept running into the same side issue: the meter. Agents need room to explore, and consumption pricing charges for every wrong turn, so in the last post I set pricing aside for its own discussion. After further thought, pricing is too narrow a frame. The real issue is control: something on every platform limits how hard your agents can work, and the only question is whether anyone in your organization actually chose it. So this post is about the two ways that limit gets set, by accident and by design, and why the difference decides what your agents are worth.
Why agents force the discussion
Agents run continuously, so the idle time that made analytics workloads cheap to host is gone. They explore, which means most of their queries are wrong turns, and every wrong turn is still a real scan against real storage. And they write heavily, materializing scratch tables, intermediate results, and branched environments at machine speed.
The accidental governor: the meter
Consumption pricing was designed around an assumption that held for two decades: you pay when you query, and you suspend when you don’t. That assumption was rational for BI, because dashboards refresh on schedules and analysts go home at night.
Agents don’t go home. Auto-suspend savings evaporate when the workload never suspends. Every wrong turn in a reasoning loop is a billed query. Meanwhile the scratch tables and branches agents materialize keep a second meter running that most capacity plans never priced in.
So the bill becomes unforecastable, and an unforecastable bill almost always gets escalated. The escalation usually lands the same way: cap the agents, restrict the queries, limit the scratch space. At that point your agent policy is being written by whoever owns the budget, which is to say by someone optimizing for a number that has nothing to do with answer quality.
I wrote in the last post that teams that throttle their agents make them worse. Exploration breadth is where agentic answer quality comes from, so metering exploration is metering accuracy. The meter is a governor, and it governs the one behavior you bought agents for.
The rebuttal
The obvious response is to go to fixed capacity and kill the meter. But if you do that, what happens next is an ungoverned agent fleet on fixed capacity will starve the workloads that carry your service-level objectives. One agent whose behavior changes overnight, a new prompt, a new model version, a new tool wired in, can eat a cluster by morning. Removing the economic throttle without replacing it is worse than keeping it.
The argument is not that agents should be ungoverned. It’s that the governor should be designed by someone who understands the workload, rather than produced as the side effect of a pricing model. The designed governor: workload management.
Agents are just users
The OcientAIQ™ Unified Data Platform handles agents differently. An agent authenticates like any user and lands in a group like any user. Service classes attach to groups, so an agent fleet is governed with the same SQL DDL that has governed analysts and applications for years. There is no separate agent-governance product to buy, deploy, and keep in sync, because the agent is not a special case.
Admission: what gets in
With OcientAIQ, a service class caps how many queries the fleet can run at once, and the overflow queues in arrival order instead of erroring. Queueing matters more for agents than it ever did for humans, because a reasoning loop that gets an error retries, and a retrying loop is a failure spiral, while a queued query simply resumes. A runtime ceiling kills the query a reasoning loop forgot about, which is the machine equivalent of the analyst who went to lunch mid-query.
Consumption: what it can eat while running
A temp disk budget caps how much disk the class can burn when a query’s working state overflows memory mid-execution, which is what the broad joins and sorts of exploratory agent queries do. Memory and CPU caps bound what the class can consume while it runs, so a runaway loop hits a wall the platform chose instead of one the budget chose. And row and column caps bound the result an agent can haul back into its context window.
Priority: who wins when they collide
A single priority number decides who wins contention, and the engine enforces it in three places at once: which query’s operators get the cores, whose data blocks move first on the network between nodes, and who spills to disk first when memory gets tight. Set the agent fleet’s priority below the reporting jobs that carry Service Level Objectives (SLOs) and the whole engine agrees on who matters, all the way down to who gets sacrificed under memory pressure. Under this pressure the agent’s working state spills before the reporting job feels anything, which is the designed governor doing exactly what the accidental one cannot.
Priority also adjusts while a query runs: a long-running agent query steps its own priority down at an interval you set, toward a floor you set. No other analytical platform we are aware of adjusts a running query’s priority without a rule firing, and most cannot adjust it at all.
Classification: how queries find their class
Queries can be routed to a service class by what the statement says, matched by pattern, before the optimizer ever sees them. That means the exploratory query shapes agents produce get caught and classed automatically, even when the fleet’s behavior changes overnight. Every other platform we looked at classifies queries by who submitted them, not by what they ask, which works right up until the “who” is a fleet whose behavior is not stable week to week.
None of this machinery was built for agents. It was built years ago to keep human workloads from trampling each other, and an agent fleet is just the newest tenant it governs, unmodified. With per-core pricing underneath it, cost never enters the conversation, so the governor tunes behavior instead of spend. The meter governs your agents by accident, workload management governs them on purpose.
The question to ask your platform
So the question to ask about your platform is: who decides how my agents behave, and did anyone actually decide? If the answer is the pricing model, then the decision was made for you, by a mechanism that predates agents and was never designed to govern them. If the answer is your own team, with policy machinery built for the job, then you chose, and you can change your mind as the fleet evolves.
For the full architecture, including how the engine underneath makes this governable in the first place, learn more about the OcientAIQ Unified Data Platform, or talk to our team about what we can do to optimize your agent workloads today.