Asim Hafeez

AI systems architect & product builder. Making AI work reliably in real business workflows. Sharing architecture, experiments & lessons.

[Asim Hafeez @asimhafeezz]

Try this review question for an AI workflow:

If it stops halfway through, can someone else tell what happened and safely continue?

Walk through one unfinished task. Check its state, evidence, next action and owner. Write down whatever the person has to guess.

[Asim Hafeez @asimhafeezz]

@dabit3 I'd give the whole agent tree one shared budget for spend, time and depth. Each child should return its changes, checks and unresolved issues to a named parent. That makes it easier to stop a failing branch and review the combined result.

[Asim Hafeez @asimhafeezz]

For a support-triage pilot, track more than classification accuracy.

Did the ticket reach the right queue? Was the handoff usable? How often did someone repair the result?

Define each measure and its denominator before judging whether the workflow helps.

[Asim Hafeez @asimhafeezz]

Before caching an AI answer, decide:

How old can the source data be?
Who is allowed to see the result?
What change should invalidate it?

Write those rules alongside the cache key. They're part of deciding when reuse is safe.

[Asim Hafeez @asimhafeezz]

A small AI workflow test set should include awkward cases:

Response lost after success. Duplicate delivery. Permission denied. Approval expired. An inconclusive status lookup.

For each one, write the expected outcome before running the test.

[Asim Hafeez @asimhafeezz]

Give retries a budget before shipping an AI workflow:

- which failures are retryable
- maximum attempts
- a total deadline
- backoff and jitter
- the handoff when the budget runs out

Check SDK retries too. Several retry layers can multiply the work.

[Asim Hafeez @asimhafeezz]

An approval step needs an expiry path.

If nobody responds, should the workflow wait, cancel or hand off?

Show the proposed action and evidence, name the decision owner, and define what happens when the request expires.

[Asim Hafeez @asimhafeezz]

@n8n_io I'd add an editorial check before the publish step. A high viral score doesn't tell you whether a clip preserves the speaker's meaning. Keeping the source timestamp with each clip makes that review easier.

[Asim Hafeez @asimhafeezz]

@businessbarista I'd version the grader and test cases alongside the prompt. If the rubric changes during a model upgrade, a higher pass rate can hide a regression. Run old and new agents against the same fixed cases and grader before comparing.

[Asim Hafeez @asimhafeezz]

3/3 Before using this pattern with another API, check:

Which endpoints support it?
How long are keys retained?
What happens if parameters change?
Can you look up the result?

Build around that API's actual contract.

[Asim Hafeez @asimhafeezz]

1/3 An idempotency key should identify the operation you're trying to complete.

If each retry gets a new key, an API may treat it as new work. Keep the operation identity stable across attempts, within the provider's documented rules.

[Asim Hafeez @asimhafeezz]

2/3 Stripe is a useful concrete example: a repeated key returns the saved result, including a 500 response.

Changing the key to get past an error can create a new operation. Check the failure and reconciliation guidance first.

[Asim Hafeez @asimhafeezz]

After a tool timeout, a useful recovery record needs:

- the intended action
- its stable operation ID
- the provider's reference, if available
- the last confirmed state
- the next check and its owner

Give the person investigating enough context to continue.

[Asim Hafeez @asimhafeezz]

@mardehaym I'd track waiting time at each handoff too. A support workflow can draft a response in seconds and still sit in an approval queue for hours. Measuring total resolution time shows whether the next investment should be a better model or a change to the process.

[Asim Hafeez @asimhafeezz]

https://t.co/QqpmMUDgNl

[Asim Hafeez @asimhafeezz]

Before an AI workflow repeats an action, answer three questions:

Do we know what happened?
Can this API deduplicate the operation?
Who owns it if the outcome stays unclear?

Write the recovery path while designing the happy path.

[Asim Hafeez @asimhafeezz]

@realmadhuguru I'd make human handoff an explicit passing outcome in the spec. For a support agent, a case it can't resolve can still pass if it reaches the right person with the relevant context. Otherwise the eval can reward confident answers over safe completion.

[Asim Hafeez @asimhafeezz]

@trq212 The scheduled-send example could use one more state: the provider accepted the message but the worker lost the response. I'd mark that as delivery unknown and check the provider before retrying. Otherwise the retry policy could send the same email twice.

[Asim Hafeez @asimhafeezz]

For a support-triage workflow, define the finished job before choosing the model.

Example: the ticket reaches the right queue, the reason is recorded, and uncertain cases go to a named person.

That gives the team something concrete to test.

[Asim Hafeez @asimhafeezz]

An AI tool call can time out after the service has done the work.

This diagram shows a synthetic example: a ticket is created, but the response is lost.

Keep an unknown state in the workflow so recovery can check what happened before another create request.