Tracing should not stop the builder
Adding observability without making telemetry initialization another reason the product could stop working.
I added Langfuse instrumentation to AGNT’s builder and agent paths to make their behavior easier to inspect.
That introduced another failure boundary. Telemetry initialization could fail, and the initial service setup treated that as a reason to exit. Instrumentation intended to explain the product had become a dependency of starting it.
Degrade visibility, not execution
I changed initialization failure from a fatal error into a warning and disabled tracing for that path when initialization failed. A no-op shutdown function let the rest of the service lifecycle continue without assuming a telemetry client had been created successfully.
I made related changes in the internal agent runner and reviewer paths. The boundary was the same: inability to initialize tracing should not, by itself, prevent the product work from continuing.
This did not make the work more observable during an outage. It deliberately accepted less visibility rather than turning that loss of visibility into another product failure.
Tracing and evaluation also remained different things. Recording an execution helped inspect what happened; it did not prove that the generated bot was good or that generation quality had improved.
Content by Stanislav Smirnov (yo@laont.me) · CC BY 4.0. Credit the author, link to this page and the license, and indicate changes when sharing.