Mapping Temporal Patterns to Agent Patterns

The Temporal design-pattern catalog holds around thirty-five patterns in twelve categories, curated by people who deploy this for a living, with a runnable example for each. It never mentions agents, and nearly every hard problem in Part XI already has a named solution in it.

The exhaustive translation lives in Appendix B: every pattern, the agent problem it solves, and where this book uses it. Look things up there.

This chapter is the other direction. Part XI has been eight chapters of individual mechanisms; this is them assembled into one system, in the order you would actually adopt them, and with the ones you probably will not need named as such.

Atlas, assembled

   inbound event
        │  signal-with-start ─────────────── entity workflow: ticket-8823
        ▼                                    ┌──────────────────────────┐
   ┌─────────────┐  update-with-start        │  alive for the case      │
   │  acknowledge│◀─────────────────────────▶│  · signals in            │
   └─────────────┘  (validated, ~40ms)       │  · queries out           │
                                             │  · durable timers        │
        ┌────────────────────────────────────┤  · continue-as-new       │
        ▼                                    └──────────────────────────┘
   agent loop (workflow)
        │
        ├── call_model ──────▶ activity · heartbeat · stream · cancel
        ├── read tools ──────▶ activities, concurrent
        └── write tools ─────▶ activities, serial, compensations pushed
                                      │
                                      ▼
                              ┌───────────────┐
                              │  saga unwind  │  on failure, LIFO
                              └───────────────┘
        │
        └── issue_credit ────▶ approval gate (update + 3-day timer)

   queues:  atlas-model 40/s · atlas-warehouse 10/s · atlas-erp 5/s
   dispatch: priority 1–5 · fairness key = tenant

Nine mechanisms, none of them invented here. That is the argument Part XI has been making since the first chapter: the hard parts of running an agent are not new problems, they are old problems arriving in a new costume.

The order you actually adopt them

Nobody adopts nine patterns at once, and the sequence is not arbitrary. Each one is triggered by a symptom you will recognise when you have it.

Read the symptom column on its own. Every entry is something you can observe rather than something you can anticipate, which is the point. These are responses, not architecture. A team that adopts all nine before shipping has bought a great deal of machinery for problems it has not yet demonstrated.

The first three are close to mandatory the moment money moves. Four through seven arrive on a schedule set by your customers rather than by you. Eight and nine are genuinely optional.

The patterns you will probably not need

Of the catalog's thirty-five, a typical production agent uses six to eight. The rest are not filler. They are answers to real problems that most systems never have. Four are adopted prematurely often enough to name:

MapReduce tree. For a backfill too wide for one parent workflow. If your fan-out is thousands rather than millions, a parent with batched children is simpler and sufficient.

Sliding window. Keeping N agents continuously in flight rather than in waves. Real, and unnecessary once a rate-limited task queue is doing the pacing. The queue already smooths the waves.

Worker-specific task queues. Pinning work to the worker holding a cache, a GPU, or a file. Correct when you have that affinity, and an unnecessary coupling when you do not.

Race / pick-first. Query two providers and take the faster answer. Attractive, and it doubles your token spend on every call to save latency you measured at 1–2% of the turn.

The general test is the one this book keeps returning to: a pattern you cannot name the triggering symptom for is a pattern you are adopting on speculation.

Where the catalog stops

The appendix names three gaps: nondeterminism sitting inside the unit of work, correctness that is not binary, and cost as a first-class failure mode. Part XI turned up four more, and they are the ones that only appear once you have actually built the thing.

The compensation set is dynamic. Classic sagas attach compensations to a designed sequence. The model chose an agent's sequence at runtime, so compensations have to live on tools in the catalogue and the stack has to be built from what actually ran. No pattern in the catalog assumes its own step list is unknown at design time.

The bottleneck is in someone else's account. Every scaling pattern in the catalog assumes that adding capacity increases throughput. For an agent, past the provider quota it decreases it. That inverts the usual advice rather than merely qualifying it.

The audit trail is also a copy of your payloads. The event history is the observability win of the whole approach, and it is simultaneously a durable record of every argument and result you passed through it. That is a compliance surface the catalog has no reason to discuss and you cannot avoid.

Steerability conflicts with optimization. Local activities block signal delivery while they run, which is a fine trade for a batch pipeline and disqualifying for an agent a person is talking to. Several catalog patterns carry this shape: correct in general, wrong for the specific property agents need most.

Part XI, in one page

The whole part reduces to four claims:

1. An agent run is a durable process with a business identity you can talk to. Not a request, and not a job.
2. A model call cannot be replayed, so it is an activity. Every other placement decision follows.
3. Durability makes the machine reliable and leaves the decisions exactly as good or bad as they were.
4. Almost everything else was already solved, under a name, by people working on problems that had nothing to do with agents.

That fourth one is why Part X spent five chapters with no AI in sight, and why this chapter is a map rather than an invention.

The catalog carries this part's shapes with the code attached: Agent as Entity Workflow and Continue-As-New for Memory for the long-lived run, Tool as Activity for the placement decision above, Saga for Tools for compensation, and Approval Gate, Updatable SLA Timer and Signal With Start for the three things a run waits on.

Part XI ends here. Next: Risk Tiers, Part XII, and classifying actions by reversibility and blast radius so the approval policy writes itself.

Takeaways

• The Temporal catalog has ~35 patterns in 12 categories and never mentions agents. Appendix B is the exhaustive translation; this chapter is the assembled system and the adoption order.
• Atlas uses nine patterns, none of them invented for agents. The hard parts of running an agent are old problems in a new costume.
• Adopt in response to symptoms, not in advance: multiple events per case, a tool with a side effect, two effects that can both fire, a human decision, growing history, 429s, a second tenant, a slow-feeling start, an existing graph.
• The first three are near-mandatory once money moves. The middle four arrive on your customers' schedule. The last two are optional.
• A typical production agent uses six to eight of the thirty-five. MapReduce trees, sliding windows, worker-specific queues, and race/pick-first are the ones most often adopted early without a triggering symptom.
• Race/pick-first doubles token spend to recover latency worth 1–2% of a turn.
• A pattern you cannot name the triggering symptom for is a pattern adopted on speculation.
• Four gaps Part XI found beyond the appendix's three: compensation sets are dynamic, the bottleneck lives in someone else's quota, the audit trail duplicates your payloads, and steerability conflicts with several standard optimizations.
• Part XI in four claims: a durable process with a business identity; model calls are activities; durability fixes the machine and not the decisions; nearly everything else was already solved.

References

• Temporal Design Patterns, the catalog this chapter maps onto agent problems.