Spotting problems early

Where problems surface

The exocorp doesn’t hide problems. Different kinds show up in different places:

• Inbox — Things that need your decision: pending approvals, recent failed runs, work items waiting on something, budget alerts. The first place to look.
• Overview — Live agent status, heartbeat health, team-level health dots, overall budget pressure. A 30-second glance.
• Team detail pages — Per-team problem lists: budget alerts, failed runs, waiting work counts, heartbeat failures. Drill into a team that’s showing “degraded” or worse.
• Work view, filtered to Stuck — 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 Knowledgebase: 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 land in the Inbox with a link to the run detail. Look at:

• The error — What specifically failed. Sometimes obvious (provider credentials expired, plugin 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 agent detail page 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 plugin, a skill) or the work should be owned by a different team.

Stuck work

Work items that should be moving but aren’t. The Stuck filter in the Work view surfaces them. 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 Inbox.
• 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, the team detail page shows the problems list: which specific things are stressed. Budget alert, failed runs, waiting work piling up, heartbeats failing. 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.