← All field notesLessons in reliability

A healthy system can still leave the work unfinished.

What tracing requests from the first message to the final handover taught us about measuring the outcome people actually need.

The lesson

Verify the outcome at the place where the work is meant to arrive.

“It is running” answers a different question.

Consider a weekly update prepared for a colleague in Slack. The draft is complete, but a connection issue prevents it from arriving. The team still has unfinished work, even though the AI teammate has already produced the answer.

The person waiting for the update needs a usable result in the right place. This is why delivery status and a useful recovery message belong in the workflow alongside the answer itself.

The business view is simpler: did the update arrive, is it usable, and does someone know what to do next? A reliability system needs to connect its technical signals to those questions.

Take this with you

Define completion from the recipient’s point of view before selecting the metrics.

Follow the flow

Follow the work all the way through

Request received

The request reached the system. This confirms the start of the work, not its completion.

Under the hood

An accepted webhook or API response establishes receipt. Correlate it with the task that follows.

Work executed

The agent used the expected tools and prepared a result. Check for partial failures and missing information.

Under the hood

Track the answer, tool actions and overall task separately so partial failures are easy to find.

Result delivered

The result reached the intended destination. A generated message may still fail to send.

Under the hood

Inspect the channel or external-service result. Distinguish an accepted send request from evidence of the intended delivery outcome.

Outcome checked

The owner can find and use the result. This completes the handover from the AI teammate to the business owner.

Under the hood

Follow a representative request to its destination. Check that the right person can find the result and that the handover includes the information they need.

Follow a task from the first request to a result the intended person can use.

Keep the stages distinguishable.

The Command Centre brings conversations, tool activity, usage and failures into view. Track the stages separately: role setup, task preparation, tool actions and delivery. Collapsing them into one green status removes information needed to diagnose a failure.

The same thinking applies to releases. Source changes, a published image and a running deployment are separate states. Even a successful deployment still needs a check of the customer path. Reporting these states separately makes it easier for the team to decide what remains to be done.

An operator needs to see a failed change even when the AI teammate is still running. Showing activity and failures together helps the owner distinguish a working role from a task or change that needs attention.

Under the hood

Follow the task across preparation, tool actions and channel delivery. Keep a clear task status and check retries for duplicate sends, especially when a connected service accepted the action before a timeout.

Test the path a person depends on.

A controlled end-to-end check needs a known starting request, an expected result and a destination the tester can inspect. It should exercise the real integration path. A mock test can check application logic, but it cannot show that a live channel or provider accepted and delivered the work.

Failure cases deserve equal attention. Try an unavailable connection, a rejected action and a timeout after a send attempt. Ask whether the person sees an honest status and whether a retry might create a duplicate. These details determine whether a team can rely on the workflow.

Measure completion where the work creates value: the destination, the recipient and the next decision. That gives engineering and business teams a shared way to improve reliability.

Take this with you

Follow one real task to its destination. A green dashboard is useful evidence along the way.

How should we measure AI agent reliability?

Track completed handovers, failed tool actions, confirmed deliveries, recovery time and duplicate sends after retries. Pair these measures with whether the recipient can use the result.

Written by Team UseGlic

Team UseGlic is the product and engineering team building the Command Centre. We build AI teammates around business roles, connected tools and clear ownership. These notes share the product decisions and practical lessons behind that work.

More about our work ↗
Put the idea to work

Every team has
a place to start.

Define the first job, connect your tools and give the work a clear owner.

Create your workspace ↗