When Something Goes Wrong

The silent no-op: the order that resolves most cases

Something was supposed to happen. Nothing did. No error anywhere. Work in this order.

One — is it parked for approval? Under the default action policy, external sends and destructive actions do not execute; they queue. A parked action looks exactly like an action that did nothing. Check the approval queue and the dashboard rail FIRST, because this is the single most common answer.

Two — was it refused by the charter? Charter refusals cite the line that refused and are logged in the KVN ledger. If someone asked the agent to create work that crosses a Negation, it did not silently fail; it declined, correctly.

Three — was it attempted at all? Check the audit log. An action never attempted is a different problem — usually a capability that is not present, which means an unconnected integration or a disabled opt-in feature.

Four — did the underlying integration break? Check the connection status and the last successful sync timestamp, not the data. A broken connection presents as absence.

Five — did it happen in a different workspace? Check the switcher. This resolves an embarrassing share of reports and costs three seconds.

Most investigations end at step one or step five.

Visibility problems

'I can't see it.' Three checks, in order.

Workspace: are they in the right one? The switcher is at the top of the sidebar.

Project access: are they on the project's Team tab? A project someone is not on is absent, not greyed out.

Role: only after the first two. A role problem looks different — they can see the page but a control is missing, rather than the page being gone.

Doing these in order matters. Starting with permissions is how workspaces end up with everyone as an admin.

Agent problems

'The agent can't do X.' Four checks.

Is the provider connected? Unconnected providers have their tools stripped entirely, so the agent genuinely has no capability rather than declining one.

Is the feature opted in? Task capture, community app tools, the remote browser, exec meetings — all default off, all strip their tools when off.

Is the autonomy level too low? At safe, risky tools are removed from the toolset. The agent is not refusing; it has nothing to refuse with.

And is it under-reporting? The agent occasionally does not know it has a capability. Naming the capability directly — 'you can search the web, can't you?' — resolves this surprisingly often.

If all four check out, then it is worth reporting.

Integration problems

'The data looks wrong or thin.' Three checks.

Connection status and last successful sync. A connection can be nominally fine while the sync it powers has stopped.

Scope completeness. A partial OAuth grant reports as Connected and then quietly returns nothing for one specific capability. This is the hardest one to see and the most common cause of 'it works except for this one thing'.

Completeness of the fetch. For large sources, a sync can report success while having pulled only part of a calendar or mailbox. The symptom is data that looks thin rather than data that looks broken, so count rather than glance.

And the rule from Lesson 9.6: if reconnecting changes nothing at all, stop reconnecting. That is the signature of a fault your credential cannot fix.

Reporting something usefully

When you have worked the checklist and it is genuinely a problem, the report that gets fixed fastest has four things.

What you expected to happen, specifically. Not 'it didn't work'.

What actually happened, including whether there was any error at all — 'reported success, no effect' is itself valuable information and narrows the search enormously.

When, and in which workspace.

And what you already ruled out. 'It is not in the approval queue and the connection is healthy' saves the first two things anyone would check.

Bug reports and feature requests have their own surfaces in Settings. Using them beats mentioning it in chat, because they persist.