Reliable agent execution is a data-consistency problem as much as an AI problem. Stateless functions may retry, workers may overlap, quotas may change, and upstream APIs may time out after applying a side effect.
Make state transitions atomic
- Create the action and its first ledger event together.
- Consume approval tokens and update quorum in one transaction.
- Claim an execution job once with a lease and clear ownership.
- Reserve quota before the upstream request.
- Append ledger events through a tenant-serialized operation.
Keep background work durable
Vercel functions are stateless, so process-local timers and fire-and-forget promises are not execution systems. Pakkawork uses persisted jobs, a notification outbox, authenticated cron workers, and dead letters for work that needs another attempt or operator review.
Handle ambiguous timeouts
Before repeating a write, check whether the intended state already exists. Verification and upstream identifiers help distinguish 'request failed before application' from 'response was lost after application.' Blind retry can duplicate emails, events, or rows.
Operate the system, not just the endpoint
- Monitor trigger heartbeats and stale execution claims.
- Track quota events and rate-bucket exhaustion by app.
- Review dead-letter age and repeated failure signatures.
- Use replay only from the last verified step.
- Register serious incidents with report and resolution clocks.
Frequently asked
Why are in-memory rate limits unsafe on serverless functions?
Different invocations do not share reliable process state. A database-backed atomic bucket applies consistently across workers and retries.
Should every failed job retry automatically?
No. Retry only when the failure is transient and duplicate execution is safe. Ambiguous or policy-related failures should be verified or sent for review.