Spotting problems early

Where problems surface

The exact interface is package-owned. A package can expose these signals through its API, notifications, or an optional UI:

• Pending decisions and alerts — Things that need your decision: pending approvals, recent failed runs, work items waiting on something, budget alerts.
• Operational summary — Live agent status, heartbeat health, team-level health signals, overall budget pressure.
• Scoped health records — Per-team problem lists: budget alerts, failed runs, waiting work counts, heartbeat failures.
• Stalled-work query — Work items that should be moving but aren’t. Repeated failed runs, long-waiting state, new triggers piling up against the same item.
• The CEO chat — For anything that needs synthesis — “what’s wrong with the customer-ops team?” — the CEO can read across surfaces and explain.

Reading the warning signs

Some problems are obvious (a failed run, a budget hard stop). The harder ones are subtler — the company appears busy but isn’t actually accomplishing anything. Things worth scanning for:

• Lots of work, weak sources — Tasks piling up but the “source” on most of them is vague (“we should probably…”) instead of concrete (a customer message, a metric change, a prior promise). The company is generating work from internal pressure, not from contact with the outside.
• Lots of discussion, no sharpening — Departments writing back and forth in comments but the underlying beliefs aren’t being tested. Agreement-shaped progress without actual learning. Check the selected knowledge package’s records: have any reviews been added recently that update the company’s view?
• Lots of eval activity, no production contact — Labs producing results but the warrants aren’t making it into production, or the company is acing its internal evals while customers are unhappy. See labs for what evals are supposed to do.
• Repeated similar work — The same kind of work item keeps coming up across different teams without a durable resolution. Either you’re missing a team that should own it structurally, or an existing team’s mandate is wrong.

Failed runs

A run is a single bounded execution attempt. Failed runs should be queryable from the package that owns them. Look at:

• The error — What specifically failed. Sometimes obvious (provider credentials expired, a component couldn’t reach an external service), sometimes the agent’s self-described reason.
• The pattern — One failed run is noise. Three in a row, or the same agent failing repeatedly across different work items, is signal. Check the package-owned agent and run records for recent failure history.
• The mandate fit — Sometimes runs fail because the work was outside the team’s real capability. Either the team needs new capability (a component, a skill) or the work should be owned by a different team.

Stuck work

Work items that should be moving but aren’t. The owning package should expose these records and may provide a Stuck filter in its optional UI. Usually one of:

• Waiting on a missing dependency — The waiting condition on the work item tells you what. Sometimes the dependency never materialized; sometimes it’s a real block (a customer hasn’t responded, a partner system is down).
• Waiting on an approval — The work item is sitting on your sign-off and you missed it. Check the owning package’s pending decisions.
• Caught in a retry loop — Multiple runs against the same work item have failed. If the agent isn’t finding a path to success, you may need to intervene: change the mandate, narrow the work, or cancel the item.

Team-level degradation

When a team’s health goes from healthy to degraded or unhealthy, inspect the problems exposed by the package that owns the team: budget alerts, failed runs, waiting work, or heartbeat failures. Drill into whichever is sourcing the problem.

If a team consistently stays degraded, that’s structural — the team’s mandate, capability, or budget isn’t right for the work it’s being asked to do. See Working with teams for how to adjust.