Serverless functions have hard time limits. Your AI analyses are slow by nature. So your platform dies by timeout exactly when it is doing its most valuable work — during my board meeting. Explain.?

The full executive answer

You are describing a real serverless failure mode, and it is one we engineered around explicitly rather than discovered in production. Three layers. First, honest budgets: every route declares its own execution budget, sized to its work — standard endpoints run tight limits, and the heavy AI generation routes declare the maximum 300-second budget, with the heaviest, roadmap generation, explicitly annotated as such in the code. Nothing relies on a default it might outgrow.

Second, and more fundamentally, the architecture does not ask a user's request to wait on the slowest work. Long-running generation is decoupled: a scheduled generation worker runs AI jobs in the background, and webhook delivery likewise runs as its own worker off a durable queue — so the interactive request path stays fast, and heavy computation happens asynchronously with results landing when ready. Idempotency keys mean any retry of a submission cannot double-run an expensive job. This is precisely the AWS Well-Architected Serverless Lens prescription: decompose long work into asynchronous jobs rather than stretching synchronous timeouts.

Third, the board-meeting scenario specifically: the response cache means an analysis already produced renders instantly — no model call at all — and the meeting artefact itself, the board pack, is generated and exported ahead of the meeting. The demo you will see today runs live generation; a real board meeting runs on pre-generated, cached, exported material. The valuable work happens before the meeting; the meeting consumes it. That is not a workaround — it is how a governed decision product should treat a board meeting.