Gorgos and observability tooling

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?

Observability is after the fact by definition. The record appears once the action has happened. A gate acts before, and can refuse.

For reversible actions, after the fact is enough. For a message already sent to a client there is nothing to undo, so the record only tells you what went wrong.

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, a record that can be overwritten is worth your trust in whoever holds access. An audit trail adds a hash chain so that rewriting history becomes visible.

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.