Agent 控制平面其實是改名後的 API gateway

I spent last Saturday adding per-run cost accounting to my agent fleet. Not a dashboard — a counter that increments on every model call, tagged with the run ID, the tool that fired it, and the person who asked. Ninety lines and one Postgres table. It's ugly and it works.

Then a colleague sent me preloop, an open-source "control plane for agents." Gateway that meters cost. Approval queue. Tool-call policy layer. Audit log. Four features, one repo, a README that reads like a product page.

My first reaction was mild embarrassment — I'd just hand-rolled three of those four. My second reaction was the interesting one: I already run all four of those things in production. I just don't call them that.

The myth, stated plainly

The pitch goes like this: agents are a new kind of workload, so they need a new kind of governance layer. Model calls are non-deterministic, tool calls have side effects, spend is unbounded, and your existing infrastructure was built for boring deterministic HTTP. Therefore: new category, new product, new thing to deploy.

I buy the premise and reject the conclusion. The "therefore" is doing all the work and none of the reasoning.

Map the four pillars onto what you already run

Take preloop's four features and translate them into boring words.

Cost metering gateway. That's an API gateway with a counter. Envoy, Kong, Traefik, nginx — every one of them has request-level metrics, rate limits, and a plugin hook where you can read a response body. Token counts come back in the response payload. Multiply by your per-token price, tag by route, ship to Prometheus. I'm not being cute here: the hard part of cost metering was never the gateway. It's the price table and the tagging discipline. Neither of those lives in the gateway, and neither of them gets easier because the gateway has "agent" in its name.

Approval queue. That's a workflow with a human step. Temporal, Airflow, a Slack bot with two buttons, a Postgres table with a status column and a cron job. The interesting design question is what happens to the agent's context while it waits — does it hold the whole run in memory, does it checkpoint, does it resume cleanly? No gateway answers that for you, and it's the part that actually bites.

Tool-call policy layer. That's authorization. OPA, Cedar, or plain RBAC if you're honest about your scale. You already have a policy engine deciding which service can call which endpoint. The only genuinely new thing is that the subject is now "agent X calling tool Y with these arguments" instead of "service A calling route B."

Audit log. That's structured logging. You already ship logs somewhere with retention and a query interface. An audit log is a log with a schema and a promise not to delete it. That's a real promise, but it's not a new category of software.

Four for four. Every pillar has an existing, battle-tested implementation that your team already knows how to operate, page on, back up, and restore at 3am.

Where the re-skin argument actually breaks

I want to be fair, because "it's just X" is the cheapest take on the internet and it's usually wrong somewhere. It's wrong here in three places.

The unit of governance genuinely changes. An API gateway thinks in requests and routes. An agent control plane has to think in tool calls with arguments. That's a real difference. "Allow read_file" is not a policy. "Allow read_file only under /tmp/run-{id}/ and only for the first twenty calls" is a policy. Route-based rules can't express that, and bolting argument inspection onto a gateway plugin gets ugly fast — I've tried, and the plugin ended up parsing JSON in a place where JSON parsing doesn't belong.

Cost has a different shape too. Per-request pricing is flat and predictable. Per-token pricing is a function of the input you didn't control, the output the model chose, and the number of retries your loop decided to do. I watched an agent retry a failed tool call fourteen times last month. Fourteen. The gateway saw fourteen requests and was perfectly happy about all of them.

And approval has latency semantics that HTTP middleware doesn't. A gateway that blocks for four minutes is a broken gateway. An agent that blocks for four minutes is a Tuesday.

So the honest read isn't "preloop is pointless." It's "preloop is a schema, not a category."

What I'd actually do with it

I'm not deploying a second control plane next to the one I already run. Two policy engines is one too many, and the failure mode — where the gateway says yes and the agent layer says no, or worse, the reverse — is exactly the kind of split-brain that eats a weekend and produces a postmortem nobody enjoys writing.

What I would do, and what I'm doing, is steal the schema. Read how preloop models a tool call, a policy decision, and an approval record. Then implement those three tables in the Postgres I already have, put the policy check in the one place my agent loop already funnels every tool call through, and let the gateway keep doing what gateways are good at: rate limits, auth, and metrics.

That gets me most of the governance with none of the new operational surface. The remainder is the part I'd have to write anyway, because it's specific to my tools and my risk tolerance, and no upstream project can guess either one.

The part I'm less sure about

Maybe I'm wrong about the operational cost. If you're a team with no gateway, no policy engine, and no structured logging — if your agents are the first real service you've ever run — then preloop isn't a re-skin of anything. It's the first version of all four things, with sane defaults, in one afternoon. That's a legitimate reason to adopt it, and it's probably the audience it's actually built for.

But that's a different claim than "agents need a new category of software." That claim is doing marketing work, not engineering work. The primitives are old. The schema is new. Buy the schema, skip the category.