+Sample synchronous acknowledgement and async callback payloads
+// Synchronous acknowledgement (outbound workflow → agent)
+{
+ "status": "accepted",
+ "tracking_id": "EXP-2026-04188",
+ "eta_hint": "~10 minutes"
+}
+
+// Async callback (worker → inbound HTTP-trigger workflow)
+{
+ "tracking_id": "EXP-2026-04188",
+ "conversation_id": "8a3f…",
+ "outcome": "approved",
+ "summary": "Approved $612.40 across 14 line items. 1 item flagged for receipt follow-up.",
+ "idempotency_key": "EXP-2026-04188:v1"
+}
+
+
+
+> **Idempotency is non-negotiable.** Async workers retry. If your callback workflow doesn't dedupe on `idempotency_key` (or `tracking_id` + a version), you *will* eventually post the same approval twice. Cheap to add up front, painful to retrofit.
+{: .prompt-warning }
+
+> **Anti-pattern: Fire-and-Forget.** The outbound workflow kicks off the work and the agent says "all done!" because nobody wired the callback. Users find out it didn't actually finish only when they ask again hours later. Always design both halves before you ship the synchronous side.
+{: .prompt-warning }
+
+> **Designing for async** comes down to three things: a clean split point at the synchronous boundary, a stable acknowledgement payload (`status`, `tracking_id`, `eta_hint`), and idempotency on the callback so a retry doesn't double-process. Keep `System.Conversation.Id` plus your business request ID flowing end to end.
+{: .prompt-tip }
+
+### Where this pattern stops fitting
+
+- You require strict transactional continuity across sync and async phases.
+- The callback channel isn't available or isn't permitted by environment policy.
+- End-user expectations require immediate completion rather than deferred fulfillment.
+
+---
+
+## 6. Combining patterns
+
+Most real solutions don't use just one pattern. They combine Conversation-First Automation with Reasoning-in-the-Loop, then layer Fire-and-Follow-up on top wherever something runs long.
+
+Here's how it usually looks:
+
+1. A user interacts with an **agent** conversationally (Conversation-First Automation surface).
+2. The agent calls a **workflow** to execute a structured process.
+3. Inside that workflow, an **agent node** handles a reasoning step (Reasoning-in-the-Loop).
+4. The workflow finishes and returns the result to the original agent.
+5. The agent summarizes the outcome to the user.
+
+Each layer keeps a clear job: conversation handles ambiguity, automation handles execution, embedded reasoning handles judgment.
+
+Same three patterns, stacked. You'll see frameworks online proposing half a dozen more. You don't need them. Section 8 walks an end-to-end expense scenario that uses this exact layering.
+
+> Keep your synchronous execution under the [100-second synchronous limit](https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-flow-create). If embedded reasoning *plus* downstream actions exceed the budget, that segment needs Fire-and-Follow-up (Pattern 3). This is the single most common reason "it worked yesterday" stops working today.
+{: .prompt-warning }
+
+---
+
+## 7. Decision framework
+
+**Start here: do you even need an agent?**
+
+The fastest win in this whole framework is recognizing the cases where the answer is *no*. If your process has well-defined inputs, doesn't need natural-language understanding, and your users are happy clicking a button or filling a form, **a plain workflow is the right answer**. Adding an agent in front of it adds latency, cost, and a new failure mode (the orchestrator picks the wrong tool) for no real upside. "We have an AI strategy" is not a reason to put an LLM in the request path.
+
+Reach for one of the three patterns below only when at least one of these is true:
+
+- The input is unstructured (free-form text, documents, images, voice).
+- The user wants to *describe* what they need rather than navigate to it.
+- Steps depend on judgment that's hard to encode in rules (policy interpretation, summarization, classification with fuzzy edges).
+- The same backend process needs to serve multiple phrasings of the same intent.
+
+If none of those apply, save yourself the architecture conversation and ship the workflow.
+
+Match your need on the left to the pattern on the right; the per-pattern sections above carry the full reasoning.
+
+| Need | Recommended pattern |
+|---|---|
+| Inject reasoning into a