Build, run, and reconcile a new meter

1. Define the meter with meter_guidance, validate_meter, and create_meter.
2. Run it in debug mode with run_meter, then check progress with get_run_status and get_run_summary.
3. Review failures with audit_trail_entries (ERROR), and create an export job for larger sets.

Investigate missing usage

1. Use list_run_history with a date filter to find the relevant runs.
2. Use get_run_summary to see the error counts for each operator.
3. Use audit_trail_entries with the ERROR export type to see failed records and their error codes.
4. Use get_operator_summary to see which operator consumed the most time, grouped by processor.
5. Use query_event_store to run SQL against the intermediate event store.

Recover a stuck meter

1. Check the status with get_run_status. Runs stuck in RUNNING, STOPPING, or INITIALIZING may need intervention.
2. Request a graceful stop with stop_meter_run, using the run ID.
3. Check the status again. If the run is still stuck after the graceful stop, you may choose a force stop, knowing the risks described earlier.
4. Review the run history and ERROR audit records to determine what happened.

Test safely with a copy

1. Duplicate the meter with duplicate_meter.
2. Run the copy in debug mode with run_meter.
3. Stop the test run with stop_meter_run.

Debug runs do not affect production billing paths.

Example requests

How responses are presented

• The agent begins with a one-sentence answer, such as the status, count, or conclusion.
• Meters, runs, and errors appear in compact tables rather than raw data dumps.
• Key terms are defined the first time they come up: meter, run, session, operator, and audit ERROR.
• Findings include supporting evidence such as the meter ID, session ID, error code, operator name, and timestamp.
• Before any write action, the agent states the action, its impact, and asks for approval.

Error records

When the agent presents ERROR audit records, it explains each field in plain language: