IT-RAT guides/tooling compared The stack All guides Console
a comparison · three tool shapes, and the half they leave

Every agent tool on the market can tell you what happened. Almost none of them can say no.

Three shapes of tooling exist today, and a team evaluating them usually compares one against another without noticing that two of the three answer only the first question: what did the agent do. The third can act, on the condition that the agent moves onto its platform first. Nobody in this list stands in front of an agent that stays where it is and answers before the call, which is the question that shows up on an invoice, in an incident review, and in front of an auditor.

one request, three ways

Watch it happen.

The same call, sent twice: once through a fleet that only watches, once through a fleet that can also refuse. Pick what the agent is trying to do and see where each one ends up.

the fleet the call
a copy Agent makes a call control plane answers before the call Model, cloud the money, the action Dashboard traces, tokens, cost 402

The tap is the whole argument. In both fleets a copy of the event goes sideways into the dashboard, and in both fleets it arrives after the thing already happened. The only difference is whether anything stood on the wire itself with the authority to stop it.

the three shapes

What is actually on the market.

Named products change monthly. These shapes do not, and every tool a team is likely to already run falls into one of them.

Aframework-native tracing

Deep inside the chain you wrote

Sold by the company behind an agent framework, and genuinely framework-agnostic: the SDKs cover the other frameworks and the model providers directly. Traces every step, captures prompts and responses, counts tokens and latency, runs evaluation suites online and offline, versions prompts, raises alerts, and clusters recurring failures into a root cause. Commercial, hosted by the vendor, with self-hosting on the enterprise tier only.

Best at: why a chain produced a bad answer, and whether a model upgrade changed behaviour.
Says of itself: observability and evaluation. It does not enforce or block anything at runtime.
Bopen observability, self-hosted

The same job, on your own metal

An MIT-licensed core you run yourself, with its own SDKs for the common frameworks and an OpenTelemetry path for anything that already emits spans, plus prompt management, model-as-judge evaluation and per-model cost accounting. The whole observability surface is free; what a commercial key unlocks is the administration around it, which is worth noticing: role permissions, retention policies, audit logs, data masking, directory sync.

Best at: the same as A, without sending prompts and completions to somebody else's cloud.
Says of itself: the run-time measures belong to separate guardrail libraries; its own job is judging afterwards whether they worked.
Ca vendor's hosted control plane

One pane over the agents that run on it

The large-vendor answer: a hosted console with a catalog, a gateway to models and tools, policy and lifecycle management. It no longer covers only agents built in its own builder, and this is the part most comparisons get wrong: agents written in other frameworks can be imported. What they cannot do is stay where they were. An imported agent is deployed onto the vendor's own infrastructure in order to be governed there.

Best at: assembling agents quickly from a catalog, with support and a contract behind it.
The entry: tiered plans with a monthly floor and capacity ceilings above it, the lowest one in the hundreds per month and the next one an order of magnitude higher.
what is left over

Planes that stand in the path and answer before the action

A gateway that gives every run a budget and answers 402 the moment it is crossed. A policy plane the agent asks before acting, which can hold the expensive one for a person. An egress plane that decides the destination before anything leaves the machine. An identity graph that knows which human a key ultimately belongs to. A record built so that somebody who does not trust you can still check it is complete. None of that is a view of the past. Each one is a decision that either happened or did not.

Not best at: explaining why the model wanted to do it. That is what A and B are for, and this stack exports into them rather than competing.
the same questions to all four

Where each one stops.

Aframework tracingBopen observabilityChosted control planethis stack
Where it sitsBeside the appBeside the appUnder the agent: it hosts itIn the request path
What comes outA trace, a score, a chartA trace, a score, a chartA queue, a chart, a policy on its own platformAn action that did or did not occur
Can it stop a runNo, and it says soNo, and it says soOn the agents it hostsYes, at the budget or the policy
Whose agents it seesYours, if instrumentedYours, if instrumentedAny, once imported and redeployed thereAnyone's, wherever they already run
What it can seeThe model callThe model callWhat crosses its own platformSpend, destination, identity, approval
Who can verify the recordYour team, after samplingYour team, after samplingYour team, in their consoleAn outsider, from the record's own proofs
Where the data livesTheir cloud, yours on enterpriseYoursTheir cloud, with an on-prem optionYours
Cost of entryPer seat, plus usageFree to self-hostA monthly floor, then capacity tiersClone the repository

Read the third row first. A tool that cannot stop a run is telemetry, however good its dashboard is, and telemetry is priced and staffed differently from a control. Then read the sixth. Dev telemetry is sampled, editable and eventually dropped, because it was built for an engineer debugging on a Tuesday. Nobody designed it to be read by a regulator two years later.

why this one

Twelve differences, and how to check each one.

A comparison you cannot verify is an advertisement. Every claim below says what makes it true and where to go and look, because the only durable advantage in this market is being the one whose claims survive being checked. The first six are visible on a single request. The second six are the ones that actually decide whether a regulated organisation can buy anything at all.

first six · in the path Differences you can see on a single request. These are the ones an engineer evaluates.
01

It answers before the call, not after it

The gateway prices every call against the run's budget and, on the one that would cross it, replies 402 with a stable error and never forwards the request to the provider. The policy plane answers allow, deny or hold before the action, and never performs the action itself. Neither of those is a notification.

The other three: shape A's own documentation says it does not enforce or block anything at runtime. Shape B's says the run-time measures belong to separate guardrail libraries, and its own job is judging afterwards whether they worked. Shape C can act, on agents that run on its platform.
Check it: the refusal is five call sites in the gateway proxy, and the comment above them says the request never reaches the provider. A drill in CI asserts the exact status.
02

The agent stays where it is, and does not have to be declared at all

Integration is one base URL. Nothing is rewritten, nothing is redeployed, no SDK enters the agent. Underneath, a kernel-level sensor reads real outbound connections, so an agent nobody registered anywhere still appears, along with the model providers it is quietly reaching.

The other three: A and B see what somebody instrumented. C sees what somebody registered, and an imported agent moves inside its runtime to be governed there, capped at three per tenant and only in cloud regions.
Check it: the detectors are called shadow_ai, unmanaged_egress, undeclared_llm and unrouted_egress, and every one of them is deterministic, with no model in the decision path.
The agent that causes the incident is the one nobody wrote down.
03

The record answers to somebody who does not trust you

Every query comes back with a completeness proof: a short receipt, checkable on its own, that the rows shown are all the rows matching the question. The verifier that checks it carries zero dependencies, so an auditor can read the whole of it before believing any of it.

The other three: developer telemetry, sampled, editable and retention-bound. In shape B, retention policies and audit logs are precisely what the commercial key unlocks.
Check it: the verifier's dependency list is empty in its manifest. That is a design constraint, not an aesthetic: every library pulled in there is one more thing an auditor is asked to take on faith.
Their record proves what it shows. This one proves that what it does not show is nothing.
04

The guardrails are themselves fired, in CI, before release

Adversarial scenarios run against a real gateway with a fake provider behind it. Burn the budget and require the 402. Ask for a forbidden tool and require the 403. Present a forged delegation chain and require it to be rejected. The exit codes differ on purpose, so the pipeline can tell a genuine hole in the defence from a broken test rig.

The other three: no analogue in any of them. Evaluation suites measure the model's answers, not whether the brakes hold.
Check it: a scenario has a required status field and it takes 402, 403 or 200, nothing vaguer than that.
A guardrail nobody has ever fired is a comment with a name.
05

Governance is not the part you pay for

Thirteen repositories, Apache-2.0 throughout, the console included. Nothing in the governance layer sits behind a licence key, a seat count or a tier.

The other three: A is commercial and closed, with self-hosting on the enterprise tier only. B's core is MIT, and what its commercial key gates is exactly the governance layer: role permissions, retention, audit logs, data masking, directory sync. C starts at a monthly floor in the hundreds, with the next tier an order of magnitude above it.
Check it: open the licence file in any repository in the stack. This is the cheapest claim on the page to falsify, which is the point of putting it here.
The thing an auditor asks for is the thing the others charge for.
06

An alert is a coordinate, and a session is not an authority

The mail that wakes somebody at night carries one link into a view, and never a button that acts. A link that acts is a permission held by everyone who received or forwarded the mail, and security gateways follow links before a human reads the sentence next to them. In the console, the privileged actions each require a fresh passkey assertion bound to that action and its arguments, rather than to whoever is signed in.

The other three: a dashboard waits to be opened, and a console button rides on the session that opened it.
Check it: the ceremony writes the signature algorithm and the credential fingerprint into the record beside the action, so a decision can be traced to a device rather than to an account.
A stolen session should not be able to pull the lever.
next six · in the room These are the ones that decide a purchase. Nobody signs off on a tool because of its architecture. They sign off because of what it answers when the auditor, the regulator or the finance director asks.
07

Post-quantum sits inside the agent loop, and it has legal dates attached

Every key, certificate and algorithm actually running is inventoried, graded for quantum risk and emitted as a CBOM in the CycloneDX format, scored against the published CNSA and NCSC timelines: new systems by 2027, legacy migration by 2030, everything by 2035. The cryptography agents themselves use is inventoried too, which is the part the established crypto-inventory vendors do not reach, because their products were designed before agents existed.

The other three: nothing at all. Observability has no view of cryptography, and the hosted control plane has none inside the agent loop.
Check it: the output formats are standards rather than ours, a CycloneDX CBOM and the NCSC timeline, so a security team can compare the result against a public reference instead of against our description of it.
A migration with a legal deadline begins with an inventory, and the inventory is the part nobody has.
08

A person can be erased without breaking the audit trail

Every payload is encrypted under its own key, so erasing a person means destroying their keys. The content becomes unrecoverable, every earlier proof still verifies, and the record itself carries the fact that an erasure happened. Nothing is re-encrypted afterwards, and records written later are reached by the same erasure.

The other three: deletion in a telemetry store is deletion. Whatever it breaks, it breaks silently, and the question of what the trail looked like before is unanswerable afterwards.
Check it: erasure is its own component, small enough to read, and the property to test is exactly this one: destroy the keys and confirm the proofs still verify.
"Delete their data" and "keep the audit trail" stop being a contradiction you have to argue about with legal.
09

A refusal is a pure function, so an auditor can rerun it

No model anywhere in the decision path. Given the same policy set and the same request, the answer is always the same, which means a refusal from six months ago can be reproduced today in front of somebody who wants to see it. The policy primitives are deliberately dull: deny a tool, deny an unattested agent, cap the number of steps, restrict the destinations, require a human above a sum.

The other three: a model-as-judge score is not reproducible, and was never meant to be. It is a measurement, not a ruling, and it moves when the judging model is upgraded.
Check it: the decision function is documented as pure, and the identity detectors follow the same rule, deterministic with no model in the path.
"Why was this refused" needs an answer that does not depend on which model version happened to answer.
10

The kill switch does not run through the thing it kills

The out-of-band control is a phone and a watch. The signing key is generated inside the device's secure element and never leaves it, not even to the app. A kill is signed on the device and the control plane verifies that signature before it acts, so the stop still works when the agent's own host is precisely what is misbehaving or compromised.

The other three: the stop button, where one exists at all, lives in the same console, on the same session, reached over the same network as everything else it is meant to stop.
Check it honestly: this one is built and not yet wired into a running stack, and its own page on this site says so in its fact table. Judge it as a design decision, not as a shipped feature.
The control worth having in an incident is the one that does not share fate with the incident.
11

Changing a limit goes through code review, like changing a firewall rule

Budgets, agent passports and policies are ordinary Terraform resources: in version control, reviewed in a pull request the way an IAM policy or a security group is, planned before they apply, and diffed when somebody has changed them outside the process.

The other three: a setting in a console, changed by whoever is signed in, leaving whatever audit trail that console happens to keep.
Check it: the provider is published on the public Terraform registry, so the resource types can be read without anyone talking to us first.
"Who raised the spend limit, and when" is a question that has an answer, or it is not.
12

The money is counted per resolved case, not per token

Token spend says how much was burned. It does not say whether the burning bought anything. The quality plane joins the cost trace to your own outcome tags and returns the price of a resolved case beside the price of an escalated one and an abandoned one, which is the same arithmetic a finance function already applies to everything else it funds.

The other three: cost per model, per trace, per user, per project. All true, and none of them an answer to whether it was worth doing.
Check it: the computation is a small named script over a flat export of outcome and cost, so the arithmetic can be repeated on your own numbers without trusting ours.
Nobody buys a lower cost per token. They buy a lower cost per case closed.

And what it costs, since none of this is free

Standing in the request path buys the refusal and charges latency for it, on every call, including the overwhelming majority that were always going to be fine. It also forces a decision nobody enjoys making: what happens when the control plane itself is unreachable, fail-open or fail-closed. Observability never has to answer that question, because nothing waits on it. That is the actual trade, and a vendor who will not name it has not thought about it.

the honest part

Where they are plainly better than us.

  • Prompt iteration. Playgrounds, prompt versioning, side-by-side runs on a dataset. That is the core loop of A and B, refined for years, and we do not have it.
  • Evaluation tooling. We do have a quality plane, and it is deliberately narrower: cost per correctly resolved case, scored on your own outcome tags. For general offline evaluation suites, theirs are more complete.
  • Assembling agents at speed. Shape C sells a catalog, support and a contract. We are not an agent-building platform and have no answer to that ask.
  • Open source is not the differentiator against B. Its core is MIT and self-hosts for free. Against A and C the licence matters; against B the argument has to be enforcement, or it is not an argument. The one thing worth saying out loud is which part B does charge for: not the observability, but the governance around it, the audit logs and retention and role permissions. Ours is Apache-2.0 including that part.
  • Maturity. All three are established products with real deployments behind them. Several planes here are younger than that, and the site says which.

None of this is a reason to pick one. If a team runs B today, the sensible move is to keep it and put a gateway in front of the model calls in shadow mode. The traces keep working and gain a spend line and a verdict per run.

what does what

The half they do not cover, by service.

All of it is Apache-2.0 and runs on infrastructure you own, and the governance planes export over OTLP into whatever tracing backend you already have. Governance data belongs in your observability stack. The enforcement decision does not belong in a dashboard.

common questions

What people ask when they have already bought one

Do we have to drop our tracing to use this?

No, and we would advise against it. Tracing answers a question this stack does not: why the model wanted to do the thing. Keep it, put the gateway in front of the model calls in shadow mode for a week, then turn on caps where the outliers are.

Our observability tool already tracks cost. Is that not the same?

Cost tracking and a cost control are different products. One tells you a run spent the money. The other answers 402 and the run does not spend it. One arrives with the invoice, the other instead of it.

Why describe products by shape instead of naming them?

Because a named comparison is wrong the week after a vendor ships a feature, and a reader who already runs one of these can map the shape to their tool in a second. The shapes are also more useful: they say what a category of tool can and cannot do architecturally, which is the part that does not change with a release note.

Could one of them add enforcement later?

They could, and the sensible assumption is that somebody will. It is a different architecture though: standing in the path means owning an availability decision, fail-open or fail-closed, on every call. That is a heavier commitment than receiving a copy of a trace, and it is why the categories have stayed separate so far.