USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksAI Agent Book
HomeAI Agent BookThe AI Harness
PreviousBuild the State Store, Memory Lifecycle, and CompactionNextEnforce Budgets, Stop Conditions, and Runaway Prevention
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

10 sections

Progress0%
1 / 10

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

Engineer Queues, Retries, Idempotency, and Recovery

Production agent runs are durable jobs, not fragile HTTP requests. A queue absorbs bursts, a lease prevents permanent ownership, checkpoints support continuation, idempotency protects side effects, and reconciliation resolves uncertain outcomes. Retries must have one owner, a classified reason, bounded backoff, and enough state to avoid restarting expensive or consequential work blindly.

What will you be able to do?

You will design the job state machine, retry taxonomy, and exactly-once-effect strategy that works over at-least-once delivery.

What is the state machine?

text
queued -> leased -> running -> succeeded | | | | | +-> waiting_for_approval -> queued(resume) | +----> retry_scheduled -> queued +-------> failed | cancelled | dead_letter

Workers renew leases. If a worker dies, another can reclaim after expiry using the checkpoint and tool-attempt records.

Which failures should retry?

FailureDefault
transient provider/network limitbounded retry with jitter
invalid structured outputat most small repair budget
policy denialno retry until inputs/policy change
approval requiredpause, not retry
invalid credentialsfail/configuration alert
uncertain mutation resultreconcile before retry
deterministic tool validationno retry

Avoid retries in HTTP client, adapter, worker, and queue simultaneously. Choose ownership and count total attempts.

How does idempotency work?

Derive a stable key from run, proposal, tool version, and normalized arguments. Persist not_started before the call, then transition to in_progress, succeeded, or unknown. On duplicate delivery, return stored success or reconcile unknown; never issue a second blind mutation.

Failure injection: Kill the worker immediately after an external system commits. The next worker should query by idempotency key or business reference and record the existing result.

How do you prove recovery?

Test worker death during model call, before tool call, after commit, while waiting for approval, and during event publication. Also test duplicate queue delivery, lease expiry, cancellation, poison jobs, and dead-letter replay authorization.

What mistakes should you avoid?

  • Retrying all exceptions.
  • Treating “exactly once delivery” as guaranteed by a queue.
  • Resetting the budget on each attempt.
  • Replaying dead letters without reviewing side effects.
  • Losing cancellation between worker leases.

Check your understanding

  1. Why are at-least-once jobs compatible with exactly-once effects?
  2. Which failures are pauses rather than retries?
  3. What should happen to an unknown mutation outcome?

Expert extension

Implement a fake queue and tool ledger. Use property tests with random crashes to prove the external counter increments at most once per proposal.

Further reading

  • Review your queue and database vendor’s official lease, transaction, and idempotency guidance before production implementation.