The Agentic Confusion: Why I Keep My Postgres Control Plane Deterministic

We are living in the "agent era." It feels like every week, a new framework promises to wrap our infrastructure in a layer of autonomous intelligence. The pitch is seductive: stop writing scripts, start setting goals. Let the AI figure out the "how."

But recently, while designing automation for an EDB Postgres AI environment managed via Hybrid Manager, I hit a wall. I was sketching out an "Agentic DB" architecture one that could autonomously scale clusters based on load and I realized something felt off.

The more I looked at the actual requirements, the more the "agent" pattern felt like a solution looking for a problem. In fact, for core database operations, it felt like a step backward.

This is the story of why I pulled back, and why the most robust architecture for Postgres isn't "agents everywhere", it’s policy-first, agent-assisted.

The Temptation of the Agent

The initial architecture I was playing with looked cutting-edge. I wanted a system that would:

• Pull CPU and memory metrics.
• "Evaluate" utilization.
• Call the Hybrid Manager API.
• Scale the cluster.

On paper, this is a perfect use case for an LLM. You give the agent access to your metrics and your API, write a prompt telling it to "keep the cluster performant," and let it reason its way to a solution.

But then I looked at the logic the agent was supposed to "reason" out.

IF cpu_avg > 80% for 10 minutes
AND cooldown_expired
AND not currently scaling
THEN increase instance tier by 1

This isn't ambiguous reasoning. It’s a deterministic policy.

There is no nuance here. There is no need for tool selection, multi-step planning, or probabilistic interpretation. By delegating this to an agent, I wasn't making the system smarter; I was making it probabilistic. I was taking a closed-form control problem—a simple if/then statement—and injecting the chaos of an LLM.

The Cost of Non-Determinism in Production

Once I saw the scaling logic for what it was, the risks of the "Agentic" approach became impossible to ignore.

In a production Postgres environment, we crave determinism. If I scale a cluster, I need to know exactly why it happened, when it happened, and what the preconditions were.

An agent introduces variability. Different model versions might interpret the "80%" threshold differently based on the phrasing of a prompt. A slight update to the system prompt might change the agent's tolerance for risk. If an agent decides to scale, and something goes wrong, the post-mortem becomes a nightmare. Instead of debugging code, you're debugging a thought process.

I realized that for infrastructure control paths (scaling, failover, configuration changes) the "intelligence" part of the loop isn't just unnecessary; it's a liability.

Blast Radius and the Audit Trail

Then there’s the question of authority.

If you give an agent access to patch_cluster, failover endpoints, or direct SQL execution, you are effectively handing the keys to your production kingdom over to a system that doesn't truly understand the concept of a "blast radius."

You can try to constrain it. You can write prompts like "Only scale one tier at a time" or "Never retry failed tool calls." But these are suggestions, not guarantees.

Compare that to a deterministic controller loop. In code, I can enforce hard bounds:

• Explicit cluster scoping.
• Hard tier limits.
• Enforced cooldown windows.
• One-action-per-cycle guarantees.

These guarantees are enforced by the compiler, not a prompt.

And for compliance? Enterprise Postgres environments demand auditability. A deterministic scaler produces a clean, structured log:

cpu_avg=84.3; threshold=80; action=patch_cluster; target=large

An agent-driven system adds layers of complexity: prompt versions, model versions, context memory state, and tool reasoning traces. When the auditors ask "Why did this change?" handing them a 500-line trace of an LLM thinking about scaling is not going to satisfy them.

The Pivot: Where Agents Actually Belong

Does this mean agents are useless for Postgres? Absolutely not. The error wasn't in using agents; it was in applying them to the execution layer.

I realized I needed to flip the architecture. Agents are terrible at control, but they are phenomenal at reasoning.

I stopped trying to let the agent scale the database, and started letting it watch the database.

1. Incident Triage

When a CPU spike hits, a static script can fire an alert. But an agent? An agent can pull slow query logs, check lock tables, analyze replication lag, and cross-reference recent schema changes. It can produce a ranked list of hypotheses: "The spike correlates with a new index creation on the users table." That is high-value reasoning.

2. Query Optimization

Interpreting EXPLAIN ANALYZE is an art. Agents excel here as copilots, suggesting index strategies or rewriting inefficient SQL. This is advisory, safe, and leverages the model's semantic understanding.

3. Cross-System Orchestration

If a PagerDuty ticket fires, an agent can pull metrics from Hybrid Manager, fetch the relevant runbook from a vector store, draft a remediation plan, and post it to Slack. It connects the dots between disparate systems. It just shouldn't be the one to press the "Execute" button.

The Mature Architecture: Reasoning Over Control

This brings me to the architecture I eventually settled on. It’s not "Agentic DB." It’s a hybrid model that keeps the reins tight.

[Agent Layer] → [Deterministic Policy Engine] → [Hybrid Manager API]
   analyze            decide + validate             execute

The Agent Layer sits at the top. It looks at the data, summarizes health, explains anomalies, and recommends actions. It says, "Hey, CPU is high, you might want to scale."

The Deterministic Policy Engine sits in the middle. It takes that recommendation (or metric thresholds) and applies the hard logic. It checks the cooldowns, validates the preconditions, and ensures the blast radius is contained. It makes the final decision.

The Execution Layer does the work. It makes the bounded API calls to Hybrid Manager and logs the result.

This model gives me the best of both worlds. I get the intelligence and insight of an LLM without surrendering control to a probabilistic system.

The Pragmatic Takeaway

The industry is rushing to wrap everything in agents, but for those of us operating Postgres in production, we have to be more discerning.

If the task is a control problem, ie.  it modifies infrastructure, use a script. Use a state machine. Use determinism.

If the task is a reasoning problem, ie.  it requires analysis, synthesis, or communication then use an agent.

The goal isn’t to avoid agents. It’s to deploy them where their strengths matter: in the passenger seat, navigating, while the deterministic engine keeps the car on the road.