[hkonsti]

Why

A request an agent was allowed to make was logged only after the connector answered successfully. If the provider failed it (a 429, a 5xx, a timeout, a revoked sign-in), the request left no AuditEntry. Only internal and database errors reached the server log, so most of these failures were not recorded anywhere. For an agent calling us thousands of times an hour, we couldn't tell how many of its calls actually worked.

What

• db: AuditOutcome gains failed, and AuditEntry gains error, a nullable column. It holds the api's error kind, plus the provider's HTTP status when there was one, e.g. provider_unreachable 429, provider_unreachable, credentials_rejected, not_found. The provider's error text is never stored, because it can contain the person's data. Migration v025_add_failed_requests.
• api (agent-side/tools.ts): every connector call (list, get, create, update, delete, commands) and every custom MCP tool call now goes through logFailure. A failure is logged as failed, with the record title and search an allowed request would have had, and the original error is then passed on unchanged. As before, a request that can't be logged fails instead of going unrecorded. Unchanged: bad params, a missing task, and a command on a record it doesn't apply to are still refused and not logged.
• activity api: entries now include error, and ?outcome=failed filters to failed entries.
• web: failed entries read "Failed to view issue “…”" and are shown in red. The activity page's outcome filter has a Failed option. An entry's dialog shows a Failed badge and an Error line in words, such as "The service turned it down for too many requests (HTTP 429)".
• seed: about 5% of allowed demo requests now fail, so the demo workspace and screen map show failed entries.
• docs: the activity log descriptions now mention failed actions.

Testing

• bun run typecheck, bun run test (all packages pass) and bun run lint (no errors, one existing warning in agent-collection-page.tsx).
• New tests: a failed command, a 429 that keeps its status, a network failure with its search, a failed custom MCP tool, a failure that can't be logged, and the failed row and its dialog in the web app.
• Applied every migration to a fresh Postgres 16 database. prisma migrate diff from the migrations to schema.prisma is empty.
• Ran the stack with the seed and checked /activity?outcome=failed and an entry's dialog.

Rollout

The internal admin reads this database directly and expects outcome to be allowed or denied (its zod schema and its Prisma client, which is generated from this schema). Once this is deployed and the first failed row is written, its activity lists may fail to parse until proxy/ is moved past this change there and the admin handles failed. Merge the two close together.