Gorgos and observability tooling
LangSmith, Langfuse and similar tools answer what happened. That is extremely useful, and an entirely different question from whether it was allowed.
What do observability tools give you?
A trace of the run: which calls, with which prompts, at what cost and with what result. Plus evaluations and annotation queues that let you measure whether a model change made answers worse.
Without this, developing an agent is guesswork. It is a layer a policy cannot replace, and Gorgos does not replace it.
Where is the difference?
A run record helps reconstruct an action. Permission control must be connected before the effect if it is to stop it. Whether a tool combines both functions must be checked in the actual deployment.
Reversibility is one criterion. Risk, permissions and the selected policy may require approval before an action even when it can be reversed later. Restoring state cannot unsend a client message; the record helps reconstruct its basis.
Observability records what happened. A gate decides what will happen. An audit needs both.
Is a run trace enough as an audit trail?
Usually not, for two reasons. First, it carries no basis for the decision: you see the call, not the rule that permitted it or the person who approved it.
Second, comparing records with a trusted hash chain helps detect changes. The reference must be protected separately: access to both records and every hash permits a rewritten, internally consistent history.
How do you use both?
Observability for development: quality measurement, cost, regressions. The gate and the decision ledger for accountability: what is allowed, who permitted it, on what basis.
These layers do not compete for budget, because they solve problems raised by different people. Engineering wants the first; the owner wants the second.